ci: cancel superseded Check runs - #4
Merged
Merged
Conversation
Each ref now has one concurrency group, so pushing again to a PR branch
or landing another merge cancels the run that is already in flight.
The macOS test job takes 3-5 minutes, so without this a burst of pushes
queues several runs whose results are obsolete before they finish.
github.ref keys the group, which keeps refs isolated: pull_request runs
use refs/pull/N/merge and push runs use refs/heads/main, so a merge to
main never cancels an open PR's run, and PRs never cancel each other.
Note this trades away per-commit coverage on main: in a rapid series of
merges only the newest commit keeps a completed run. The tip of main is
always verified; intermediate commits may not be. To keep every main
commit built, make cancellation conditional instead:
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan11 finding(s) HIGH/CRITICAL: 11
Snippets are redacted; ThreatCrush never prints matched credential material. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change
The macOS test job runs 3–5 minutes. Without a concurrency group, a burst of
pushes to a PR branch — or several merges in a row — leaves multiple runs
queued whose results are already obsolete by the time they finish. This keeps
one in-flight run per ref and cancels the rest.
Why
github.refkeys the groupRefs stay isolated, which is what makes
cancel-in-progress: truesafe here:github.refpull_requestrefs/pull/N/mergepushto mainrefs/heads/mainSo a merge to
mainnever cancels an open PR's run, and no PR can cancelanother's. Only genuinely superseded runs on the same ref get killed.
Tradeoff worth knowing
This gives up per-commit coverage on
main. In a rapid series of merges, onlythe newest commit keeps a completed run — the tip of
mainis always verified,but intermediate commits may not be, which costs some
git bisectgranularity.That partially offsets the trunk coverage added in #3. If you'd rather keep
every
maincommit built and only dedupe PR runs, change one line:I went with unconditional cancellation since that matches the follow-up as
described, but the conditional form is a defensible default — happy to switch.
Verification
This PR's own run exercises the file. Cancellation behavior only shows up under
concurrent runs, so it isn't directly observable here; the group key is the part
worth reviewing.
🤖 Generated with Claude Code