ci: stop commits to main from serializing into one concurrency queue - #638
Merged
Conversation
The concurrency group was keyed on `github.ref`, which is `refs/heads/main` for every push to main, and `cancel-in-progress` is false for pushes. So every commit to main queued behind the previous one, and because GitHub permits only one *pending* run per group, each new commit cancelled the previously-pending run — intermediate commits on main were never built. Key pushes by `github.sha` instead so each commit gets its own group. Pull requests keep collapsing onto one group (now the PR number rather than the merge ref) so a new push still supersedes the running check. docs.yml stays serialized on purpose — it deploys to gh-pages, where concurrent runs can race and publish an older build last. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M4oTuMi5F5wkzwribhTKdu
Adopts the common head_ref||run_id idiom's run_id fallback, so a commit that lands on two triggering refs (roll/* then main) does not queue against itself, and cancel-in-progress can be an unconditional true -- inert on pushes because each push group holds a single run. Keeps the PR number rather than head_ref as the pull_request key: head_ref is a branch name, so two fork PRs both using patch-1 would share a group and cancel each other. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01M4oTuMi5F5wkzwribhTKdu
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.
Commits to
maincurrently queue behind each other instead of building in parallel, and most of them never build at all.Cause
All three workflows key concurrency on
github.ref, andcancel-in-progressevaluates tofalsefor pushes:For every push to
main,github.refis the same string (refs/heads/main), so all of them land in one group and serialize. Worse, GitHub keeps only one pending run per group — a newly queued run cancels the previously-pending one. With a ~20 minute test matrix, a burst of merges means only the first and last commits ever build.Observed on
maintoday:63804364ebaf2b3b1e7c974db9944ebaf2bis main's HEAD. Three cancelled-in-a-row also show up on 2026-06-25.Fix
Key pushes by commit instead of by ref:
pull_request.numberis null, so the group is the SHA: every commit gets its own group, nothing queues, nothing gets cancelled.cancel-in-progress. Using the PR number rather than the merge ref also avoids two fork PRs sharing a branch name colliding.Applied to
build.ymlandverify_type_generation.yml.docs.ymlis left serialized on purpose — it pushes togh-pages, where concurrent deploys can race and publish an older build last. Added a comment so it doesn't read as the same oversight.🤖 Generated with Claude Code
https://claude.ai/code/session_01M4oTuMi5F5wkzwribhTKdu