ci: serialize Build runs per ref - #7
Merged
Merged
Conversation
Merging #5 and #6 twenty-eight seconds apart put two Build runs on main at once, and the older one's release step failed with HTTP 403 on POST /releases while the newer one created v1.0.10 without trouble. The 403 was never explained — the job holds contents:write, the protect-main ruleset targets branches rather than tags, and the same configuration succeeded moments later — but two release jobs racing to create refs in one repository is not a state worth keeping either way. The concurrency group queues runs per ref. On main nothing is cancelled, so every merge still produces its release; on pull requests superseded runs are cancelled as before, since a stale PR build has nothing to publish. The known trade-off: three merges in quick succession would leave the middle run queued, and GitHub drops a queued run when a newer one arrives — that commit would get no release. For a repository that merges a few times a month that is a better failure mode than a race. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Follow-up to the failed release run after #5 was merged.
What happened
#5 and #6 were merged twenty-eight seconds apart, putting two
Buildruns onmainsimultaneously. The older run's release step failed:The newer run created
v1.0.10thirty seconds later without trouble, sov1.0.9is simply missing — the tag was never created, and the maintainer chose to leave the gap rather than publish a superseded intermediate build.The 403 itself was never explained: the job holds
contents: write, theprotect-mainruleset targets branches rather than tags, and the identical configuration succeeded moments later. What is clear is that two release jobs racing to create refs in one repository is not a state worth keeping, regardless of whether that race caused this particular 403.Change
Runs now queue per ref. On
mainnothing is cancelled, so every merge still produces its release. On pull requests superseded runs are cancelled as they effectively were before — a stale PR build has nothing to publish — which also keeps macOS runner slots free.codeql.ymlalready carries the same pattern with unconditional cancellation.Known trade-off
Three merges in quick succession would leave the middle run queued, and GitHub drops a queued run when a newer one arrives — that commit would get no release. For a repository that merges a few times a month, a missing release on a triple-merge is a better failure mode than two release jobs racing.
Verification
actionlint .github/workflows/build.ymlpasses. The effect itself is only observable onmain, since it is the queueing behaviour of two concurrent pushes.