ci: cancel superseded pull request runs - #273
Conversation
`test.yml` has no concurrency control, so pushing a new commit to a pull request leaves the previous commit's jobs running to completion even though nobody will read their results. Add a workflow-level group. Only pull request runs share it; every other run gets `github.run_id`, a group of one, because a group holds at most one pending run and GitHub evicts that pending run whenever a newer one enters the group — `cancel-in-progress` protects the running run, not the queued one. Pushes to `main` therefore always complete: they publish the coverage later comparisons are measured against, and losing one would also hide a breakage already on the default branch. `benchmarks.yml` already had a group, but with an unconditional `cancel-in-progress: true`, so a push to `main` cancelled the in-flight benchmark run for the previous `main` commit. CodSpeed compares a pull request against the benchmark result of its base commit, so that leaves later comparisons without a baseline. It now uses the same expression. `release.yml` is untouched: its string-form group leaves `cancel-in-progress` false, so releases queue rather than cancel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016aGHrb1YaEvaGwNELGEHjF
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #273 +/- ##
=======================================
Coverage 99.25% 99.25%
=======================================
Files 15 15
Lines 805 805
Branches 140 140
=======================================
Hits 799 799
Misses 6 6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. WalkthroughBoth workflows now define concurrency settings. Pull-request runs share groups based on the workflow and pull-request ref, and newer runs cancel older runs. Other runs use a unique Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The workflow changes match the intended pull-request cancellation and non-pull-request isolation behavior and are ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
test.ymlhas no concurrency control at all, so pushing a new commit to a pull request leaves the previous commit's 28 jobs (three operating systems × nine Node.js versions, pluslint) running to completion even though nobody will read their results.Why non-pull-request runs get their own group
Only pull request runs share a group. Everything else gets
github.run_id, a group of one, and the reason is not obvious:cancel-in-progress: falseprotects only the run that is already executing. A concurrency group holds at most one pending run, and GitHub evicts that pending run whenever a newer one enters the group regardless of the flag — "any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place." With onemainrun executing and a second waiting, a third push would evict the second. A group of one cannot be cancelled or evicted.That matters because
mainruns publish the coverage later comparisons are measured against, and losing one also hides a breakage that is already on the default branch.benchmarks.ymlalso fixedIt already had a group, but with an unconditional
cancel-in-progress: true— so a push tomaincancels the in-flight benchmark run for the previousmaincommit. CodSpeed compares a pull request against the benchmark result of its base commit, so two merges in quick succession leave later comparisons without a baseline to use. It now uses the same expression.Untouched
release.yml— already uses the string formconcurrency: ${{ github.workflow }}-${{ github.ref }}, which leavescancel-in-progressfalse, so releases queue instead of cancelling.dependabot.yml— one short job that approves and enables auto-merge; cancelling it halfway could leave a pull request without the auto-merge it was about to turn on.Verification
actionlint1.7.7 is clean on all four workflows, and I checked that this means something by typo'ing the expression togithub.event_nam, which it catches at exactly that line. Both files are Prettier-clean.The same change is going to
webpack-sources,watchpack,schema-utilsandwebpack-cli, and is already open onenhanced-resolve(webpack/enhanced-resolve#673),webpack-dev-server(webpack/webpack-dev-server#5742) andwebpack-dev-middleware(webpack/webpack-dev-middleware#2412).🤖 Generated with Claude Code
https://claude.ai/code/session_016aGHrb1YaEvaGwNELGEHjF
Generated by Claude Code
Summary by CodeRabbit