When a pull request is pushed multiple times in sequence (e.g. to fix small
errors that are noticed post-submission), a backlog of builds ends up needing
to be cleared out before your new update can be built. If you push N times, N
builds are queued and need to clear out first.
This can cause higher latency for *every* PR since the pool of public runners
is shared, and in general seems uneconomical and inefficient since 99% of the
time you want to build the new version ASAP.
Luckily GHA has a universal solution to this: use the `concurrency` directive
to group all builds for a PR under a name, and when a new build appears in that
group, cancel all builds in the group that are in-progress.
Taken from this useful blog post: "Simple trick to save environment and money
when using GitHub Actions"
https://turso.tech/blog/simple-trick-to-save-environment-and-money-when-using-github-actions
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The workflow that was supposed to enable auto-merge for PRs from
Dependabot is failing like this:
```
Message: Resource not accessible by integration, Locations: [{Line:1 Column:72}]
```
I can't figure out why it's failing (maybe
https://github.com/cli/cli/issues/1314?), so let's just remove it.
It seems that there's no way to just enable auto-merge without
specifying a merge strategy (presumably because some projects allow
several GitHub merge strategies), so I guess we'll have to live with
the strategy being duplicated between here and the project settings.
To merge a Dependabot PR, I have to enable auto-merge (two clicks,
including one to confim) and then review and approve it. Since our
branch protections require the PR to be approved, it seems that that
should be enough. This patch adds a GitHub action that calls runs the
GitHub CLI to do that. It is based on
https://dev.to/slashgear_/how-to-automatically-merge-dependabot-pull-requests-with-github-actions--30pe
