We'd like to start releasing monthly so that we don't fall quite so far behind... based on past commit frequency, most of these releases will only contain merged :dependabot: PR's bumping our deps, but this way we find out quickly if a dep breaks our action.
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 checks for _any_ delta in the git repo, not just the `dist/`
directory. Any change should fail CI until it's either committed or
added to `.gitignore`.
Additionally, I clarified the script name/code slightly to explain why
it's needed/handled separately from checking for uncommitted files.
The app token will persist even as users come/go from the :dependabot:
team.
It also allows us more finegrained access controls from the app settings
page if we need to suddenly lockdown something, we don't have to rely on
the person who created the PAT.
There are multiple deps that are `eslint`-related, and since they're all related to a linter, it's very safe to merge them as a single group.
So try kicking the tires on the new "grouping" feature that the :dependabot: team is working on.
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.
Several of these job steps that use `GITHUB_TOKEN` are read-only
operations, so they don't need elevated permissions for the
`GITHUB_TOKEN`.
And the jobs that _do_ need elevated permissions we're already using a
PAT, so it's not even using the `GITHUB_TOKEN`.
So no need for any custom permissions on the `GITHUB_TOKEN` at all.
