ci: cancel superseded pull request runs - #673
Conversation
Pushing a new commit to a pull request leaves the previous commit's jobs running to completion even though nobody will look at their results. For `Test` that is 28 jobs (three operating systems by nine Node.js versions, plus lint), and `Cross-runtime` adds three more. Give `Test` and `Cross-runtime` the concurrency group `Benchmarks` already had, so a new commit cancels the runs it supersedes. Runs for `main` are exempt everywhere, including in `Benchmarks`, which cancelled them until now: they are the baseline Codecov and CodSpeed compare pull requests against, and cancelling one would also hide a breakage that is already on the default branch. `Release` keeps its existing group, which queues rather than cancels, and `Dependabot` is left alone: cancelling it halfway could leave a pull request without the auto-merge it was about to enable. 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 (3)
🚧 Files skipped from review as they are similar to previous changes (2)
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review. WalkthroughThe benchmark, cross-runtime, and test workflows now use conditional concurrency groups. Pull request runs share groups based on workflow and ref and can cancel in-progress runs. Non-pull-request runs use unique run IDs and are not cancelled. Comments document the behavior, including preservation of Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to Pull-request runs are cancellable and non-pull-request runs remain isolated; no merge-blocking risk is established. 🚥 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Advanced
Run ID: 266b531d-dd9d-4442-a164-7e6db5c8b99a
📒 Files selected for processing (3)
.github/workflows/benchmarks.yml.github/workflows/cross-runtime.yml.github/workflows/test.yml
Included review availability: Your plan provides up to 4 included reviews per hour; 2 remain after this review.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #673 +/- ##
=======================================
Coverage 98.14% 98.14%
=======================================
Files 49 49
Lines 10046 10046
=======================================
Hits 9860 9860
Misses 186 186
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:
|
Merging this PR will degrade performance by 85.11%
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing |
`cancel-in-progress` only protects the run that is already executing. A concurrency group holds at most one pending run, and GitHub cancels that pending run whenever a newer one enters the group, whatever `cancel-in-progress` says. Keying every run of a workflow on the ref therefore did not deliver what the comments promised: with one `main` run executing and a second waiting, a third push would have evicted the second, which is exactly the "two merges in quick succession" case this is meant to protect. Group only pull request runs by ref; give everything else `github.run_id`, so each is a group of one that can be neither cancelled nor evicted. Also corrects the matrix in the comment: nine Node.js versions, not ten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016aGHrb1YaEvaGwNELGEHjF
|
CodSpeed Performance Analysis is failing here with "Performance Regression: -85.11%":
This PR changes three YAML files under So the check is measuring something other than this branch, and it is worth recording that plainly because the same phenomenon is currently red on #667 too, where it is much harder to dismiss confidently. Taken together:
One benchmark swinging 60–97% in both directions across branches that do not touch it — including one that cannot touch it — is the measurement, not the code. CodSpeed says as much itself on #667: "Different runtime environments detected — some benchmarks with significant performance changes were compared across different runtime environments, which may affect the accuracy of the results." This PR may actually help with that. I am not touching the diff for this: there is nothing in three YAML files to make faster. If you want the check green before merging, the regressions can be acknowledged in the CodSpeed dashboard — a maintainer action I would not take unasked. Generated by Claude Code |
Pushing a new commit to a pull request currently leaves the previous commit's jobs running to completion, even though nobody will read their results.
Testalone is 28 jobs per push — three operating systems × nine Node.js versions, pluslint— andCross-runtimeadds three more. PR #667 went through five pushes this afternoon, so roughly 130 job-runs were obsolete the moment they started.Change
TestandCross-runtimeget the concurrency groupBenchmarksalready had:github.workflowis in the group key, so the workflows never cancel each other. On apull_requesteventgithub.refisrefs/pull/<n>/merge, which is unique per pull request, so one PR's pushes never cancel another's.Why
mainis exemptThe condition is the point of the change, not decoration.
Benchmarkscancelledmainruns until now, and this stops that too:maincoverage in the same way.mainrun hides a breakage that is already on the default branch.Left alone deliberately
Release— already hasconcurrency: ${{ github.workflow }}-${{ github.ref }}. The string form defaultscancel-in-progressto false, so releases queue instead of cancelling, which is what you want for something that publishes.Dependabot— 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, and there is nothing to save.Verification
actionlint1.7.7 passes on all five workflows. I checked that this means something by typo'ing the expression togithub.event_namand confirming it is caught:All five workflows also still parse as YAML and are Prettier-clean. No changeset: CI-only change, matching how previous
ci:commits were handled here.🤖 Generated with Claude Code
https://claude.ai/code/session_016aGHrb1YaEvaGwNELGEHjF
Generated by Claude Code
Summary by CodeRabbit