fix(release): job-level concurrency for the pull_request-triggered jobs - #35
Merged
Merged
Conversation
Review finding on the caller PRs: release-candidate and release-publish also start on every PR closing on their branch, and GitHub keeps one pending run per concurrency group, so a workflow-wide group let an unrelated closure evict a queued cut or publish — silently, since pull_request.closed never refires. The groups now sit on the gated jobs (propose, cut, publish); a skipped job holds no slot. Co-Authored-By: Claude Fable 5.1 <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.
Review finding on the caller PRs of #34 (megaeth-labs/mega-evm#378, megaeth-labs/stateless-validator#210), raised by both Codex and the Claude reviewer.
release-candidate.ymlandrelease-publish.ymlalso start on every PR closing on their branch; the jobif:then skips the noise. But a workflow-levelconcurrencygroup is entered before any job runs, and GitHub keeps one pending run per group: with a run in progress and a realcutorpublishqueued, the next unrelated closure replaces the queued run and cancels it.cancel-in-progress: falseonly protects the running one. Sincepull_request.closednever refires, the lost cut or publish is unrecoverable by re-dispatch.Fix: the groups move to the gated jobs —
proposeandcutget their own lanes,publishkeeps its per-release-branch key — as job-levelconcurrency. A skipped job never queues, so it holds no slot in a job-level group and cannot evict anything.release-settleandon-releasekeep their workflow-level groups: they have no noise triggers.README updated to say so. Same change goes to mega-agents (follow-up PR, #299 had already merged) and is pushed to the open mega-evm and stateless-validator PRs.
🤖 Generated with Claude Code