ci: cancel superseded pull request runs - #341
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
|
|
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 2 included reviews per hour; 1 remains after this review. WalkthroughThe benchmarks and test workflows now use event-specific concurrency policies. Pull request runs share a ref-based group and cancel older runs. Pushes to Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to No merge-blocking workflow concurrency issue was identified. 🚥 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 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #341 +/- ##
=======================================
Coverage 92.19% 92.19%
=======================================
Files 8 8
Lines 1307 1307
Branches 385 385
=======================================
Hits 1205 1205
Misses 96 96
Partials 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:
|
test.ymlhas no concurrency control at all, so pushing a new commit to a pull request leaves the previous commit's 43 jobs running to completion even though nobody will read their results. That is the largest fan-out of any repository I have looked at in this pass — three operating systems × eight Node.js versions × polling on/off, minus six exclusions, pluslint.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
tapable(webpack/tapable#273),webpack-sources,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