Adds a workflow that publishes a new version of the immutable action package
for this action on every release.
Co-authored-by: Nish Sinha <nishnha@github.com>
We're about to cut a new major version of this action,
and we don't anticipate any further releases of the `v1`
line.
So I simply updated the automation to float the `v2` tag.
Technically we could make it so it intelligently looks at
the release number and updates the appropriate tag, but
that'd be a bit more work and we don't need that complexity
in this repo right now given our very infrequent cadence of
bumping major versions.
As explained in a [code comment](f2f0ad1522/.github/workflows/release-move-tracking-tag.yml (L11-L28)):
```
# We have a choice - defensiveness vs convenience:
# 1. Be defensive by filtering if the release doesn't look like a normal
# version, or if it's a patch release to an older version... the logic
# gets tricky quickly. Easiest way to be 100% sure is stop running this
# on `release` and instead require a human to manually run this workflow
# after they tag a release.
# 2. Minimize the upfront hassle by assuming every release is a normal
# version release and the latest one. Today both are resoundingly true
# as this repo isn't that active/busy, so we don't worry about
# multiple release branches, pre-releases, etc.
#
# For now I've gone with option 2, as it is much more convenient and if we
# typo something during a release it's easy to fix by immediately tagging a
# correct release. And if we don't notice the typo, well, in that case
# requiring a human to manually run the workflow wouldn't have protected us
# either, we'd have had to filter by only things that look like versions.
# Anyway, for now this is good enough, and if it gets to be a problem down
# the road we increase the robustness of this.
```
This adds a workflow for floating the `v1` tag to the latest release.
This way we reduce the chance of someone fat-fingering the necessary
`git` commands.
Add a workflow for creating release PR's. This way we don't have to do
it locally, and we guarantee the `npm` version used to generate the
version bump is consistent and stays in-sync with the repo instead of
whatever the dev happened to have on their local computer.
Over in
https://github.com/dependabot/fetch-metadata/pull/360#discussion_r1196155497,
I noticed that bash was complaining about this script:
```bash
bin/bump-version: line 9: ((: patch_level == 'major' || patch_level == 'minor' || patch_level == 'patch': syntax error: operand expected (error token is "'major' || patch_level == 'minor' || patch_level == 'patch'")
```
I started to dig into it, but the `while` loop isn't needed, the `case`
statement felt unecessarily complex so I simplified it to use an `if`
statement.
I also changed the argument from a flag-based argument to simple ordered
argument, as again it seemed simpler and it matches the style of the
bump version script over in `dependabot-core` so it's easier for
engineers working across repos. If we later have additional flags, we
can always switch it back later.
Lastly, I found `patch_version` confusing given that `patch` is a
specific value that can be used, so I renamed it to `version_type`.
There's a chicken-and-egg scenario where we don't have the release notes
to include in the version bump PR until we create a GitHub release...
but we don't want to publish the release until the commit bumping the
version actually lands.
The last few times I've cut a `fetch-metadata` release, I've been
surprised how I always forget the intricate dance to navigate this
chicken-and-egg.
I don't think the juice is worth the squeeze... no one really looks at
the changelog notes in the PR, and if in fact having the release notes
two different places introduces a risk of drift because both the PR
description and the git tag for the release can be edited later on...
only the commit history is actually immutable. So if either is edited
w/o editing the other, they're out of sync.
The odds of that are low--we rarely edit release notes--but still life
is simpler if we merely point the commit/PR description at the URL for
the release notes and manage those in a single place.
This also lets us script creating the PR, which is one less thing to do
manually.
Add a `skip-verification` (boolean) option:
- If `true`, the action will not validate the user or the commit verification status
- Defaults to `false`
Allows for scenarios where users want to add or amend commits on the Dependabot PR, and those commits will not come from the :dependabot: user.
There's a fair bit of discussion on this use case and also why this isn't the default behavior, see:
* https://github.com/dependabot/fetch-metadata/pull/336
* https://github.com/dependabot/fetch-metadata/issues/332
While running a release, at this point in the instructions I was on the `v1.3.5-release-notes` branch.
So `git pull` isn't guaranteed to pull updates on `main` etc.
Since we're going to checkout the release tag, a `fetch` is all we need here.
I saw "locally" and thought I had to do this on my laptop and couldn't do this in a codespace for some reason...
But I tested and turns out a codespace is just fine, so remove mention of "locally"
