ci(release): serialize release runs so back-to-back merges can't race - #172
Merged
Merged
Conversation
release.yml triggers on every push to main with no concurrency guard, so merging a second PR before the first release finishes starts two semantic-release jobs at once. Both compute a version from the same tag history and both try to tag, push and publish it; one of them loses. This is not hypothetical — it is why resortable PRs have to be merged one at a time, waiting for each Release run to finish before starting the next. cancel-in-progress is false deliberately. Cancelling the queued run would mean the commits merged second never get released at all. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_016znpWBRUXSTsHbJcKmVpN6
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
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.
Found while merging #168, #170 and #171 in one session: they had to go in one at a time, waiting for each Release run to finish, because nothing stops two from running at once.
release.ymltriggers on every push tomainand declares noconcurrency. Merging a second PR before the first release finishes starts twosemantic-releasejobs concurrently. Both read the same tag history, both compute the same next version, and both try to tag, push and publish it — one loses, and which one is a coin flip.The change
cancel-in-progress: falseis the load-bearing half. The default (true) would cancel the queued run, which means the commits merged second would never be released at all — a quieter failure than the race it replaces. With itfalse, the second run waits and then publishes normally.Grouping on
github.refkeepsmain,developandalphaindependent, since each is its own release channel.Verified
npx prettier --check .github/workflows/release.yml— clean.Behaviour cannot be verified before merge: the workflow only runs on push to a release branch, so the guard is exercised the first time two PRs merge close together.
Self-review: skipped — three-line workflow change, no application code.
🤖 Generated with Claude Code
https://claude.ai/code/session_016znpWBRUXSTsHbJcKmVpN6
🤖 Created with Claude Code · origin
interactive· 2026-09-04 00:52 UTC