Take the bootstrap sweep off pull requests - #127
Conversation
|
Warning Review limit reachedNext included review available in 59 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe ChangesWorkflow trigger update
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested reviewers: Merge Risk: ⚪ Minimal · up to The bootstrap sweep still runs on master pushes while no longer consuming CI capacity for pull requests, schedules, or manual runs. No actionable merge-blocking risk remains. 🚥 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 |
The matrix is 34 released versions x 2 envs, so it is 68 jobs. docs/dev/branching.md case 4 sends every workflow change to master. Three of them moved there today, and each queued its own 68 bootstrap jobs behind itself: approved, no failures, unmergeable for hours, while sweeping plugins that were released weeks ago. Every version in that matrix tests a plugin that is already out, so nothing a pull request changes can change the result. The nightly and a push to master still run it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ed0db16 to
1f388b4
Compare
| github.event_name == 'workflow_dispatch' || | ||
| (github.event_name == 'push' && github.ref == 'refs/heads/master') || | ||
| (github.event_name == 'pull_request' && github.base_ref == 'master' && github.event.pull_request.head.repo.fork == false) | ||
| (github.event_name == 'push' && github.ref == 'refs/heads/master') |
There was a problem hiding this comment.
The problem can be solved differently - in the case of this repo, we can cancel old workflow runs.
There was a problem hiding this comment.
Good point, and I took it: c5a9431 adds the concurrency block, so a second push to a pull request cancels the run it replaced.
I kept the if: change too, because the two fix different things.
Cancellation helps when one pull request runs twice. It does nothing when three pull requests are open, which is the case that filled the queue last week: each one still starts its own 68-job bootstrap sweep, and none of them supersedes the others.
The if: change is about what the job proves, not about how long it holds runners. master-bootstrap-tests runs 34 already-released versions against already-released plugins. No change in a pull request can change that result, so the run is not a slow signal, it is no signal.
The group is the run id for everything that is not a pull request. Grouping those by ref would make a nightly wait for a master push instead of running, which is worse than what we have now.
coutoPL's point on the review: a stale run can be cancelled instead. That is true and worth having, so it is here. It covers a different case, though. Cancelling helps when the same pull request is pushed twice. It does nothing for three open pull requests, which still queue their own bootstrap sweep each. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The problem
master-bootstrap-testsis a 34-version × 2-env matrix — 68 jobs — and it ran on four triggers:docs/dev/branching.mdcase 4 sends every pipeline and workflow change tomaster. Three such PRs moved there today — #120, #122, #126 — and each one queued its own 68 bootstrap jobs behind itself. On #122 the e2e legs it actually needed had all finished:Approved, no failures, and unmergeable for hours — waiting on a sweep of plugins that were released weeks ago.
The change
One clause removed: the pull-request trigger.
Every version in that matrix tests a plugin that is already out, so nothing a pull request changes can change the result. The nightly still sweeps them, a push to
masterstill runs it — that is the moment the released set can actually move — and the manual dispatch is still there when someone wants it.🤖 Generated with Claude Code