Repository navigation
ci: run the full CI matrix on merge queue groups - #858
Conversation
Add a merge_group trigger to ci.yml so a merge queue can test each pull request against the current main before it merges. Every job behind CI / Required runs unchanged on merge_group: no job is conditional on the event, none reads pull-request-only context, the distribution builds check out github.sha (the merge group commit), and only pull_request runs cancel in progress, so queue runs are never cancelled by a newer run. A policy test pins the trigger, the concurrency settings, and the absence of pull-request-only context in the required jobs and the reusable workflows they call.
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Merge queue trigger and validation .github/workflows/ci.yml, tools/ci/tests/test_required_ci.py |
The workflow adds the merge_group trigger. The test checks workflow triggers, concurrency settings, the required job name, and restrictions for mandatory and reusable jobs. |
Suggested reviewers: svonava
Priority:
Merge Risk: 
a1cef
-
The merge queue trigger is consistent with the existing required CI workflow and presents no actionable merge-blocking risk.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files. (1 skipped: 1 … Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title clearly and concisely describes the main change: running the full CI matrix for GitHub merge queue groups. Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
Full details: Docstring Coverage
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 3 functions across 1 files. (1 skipped: 1 unsupported.)
Resolution
Write docstrings for the functions missing them to satisfy the coverage threshold.
-
Finishing Touches: 💡 1
-
📝 Generate docstrings: 💡
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Problem
CI / Requiredis computed when a pull request's CI runs, against the main of that moment. Branches are not required to be up to date, so a pull request can merge days later on that old result. Three of the last 20CIpush runs on main failed this way:CI / Requiredpassed on the PR head#824's lock change predates the bundle-lock binding check from #802; #809 and #819 predate the RUSTSEC-2026-0382/0383 advisories.
Requiring branches to be up to date would close the gap, but
dismiss_stale_reviews_on_pushis on, so every forced update would dismiss the approval and need a new review. A merge queue tests the pull request merged onto the current main (and onto the entries ahead of it) without pushing to the pull request branch.Change
ci.ymlgains amerge_group:trigger. Nothing else in the workflow needs to change for it:CI / Requiredhas anif:, andCI / Requiredkeepsif: always();release-python.yml,release-npm.yml), readsgithub.event.pull_request,github.head_reforgithub.base_ref;github.sha, which onmerge_groupis the merge group commit, sorelease_guard.py buildcompares the checkout with the commit under test;github.ref, which is unique per queue entry (gh-readonly-queue/main/pr-<n>-<sha>), and onlypull_requestruns cancel in progress, so a queue run is never cancelled by another run.test_required_check_reports_on_merge_queue_groups(run byCI / Policy) pins the trigger set, the concurrency settings, and the absence of pull-request-only context in the required jobs and the reusable workflows they call. Each of these mutations fails it: dropping the trigger,cancel-in-progress: true, checking outgithub.event.pull_request.head.shainrelease-python.yml, and passing it assource_ref.No other workflow has an unfiltered
pushtrigger, so queue branches start no extra push runs.Full job set on merge_group
I measured whether a lighter job set would be safe on
merge_group. Over the last 300CIpush runs on main (2026-10-02 to 2026-10-26), 20 failed. The failing lanes were Python (7), Rust (4), Fresh bootstrap (3), TypeScript (3), Helm (2), Policy (2), and one each for Bundle resolution, Contracts, CPU containers, Live SDK CPU and Python distributions. Every lane except npm distributions has broken main at least once.A lighter set would also not be faster.
CI / Pythonis the critical path on its own (median 19 min on push and 37 min on pull requests, p90 35 and 46 min), and it is also the lane that failed most often. The next longest, CPU containers, has a median of 14 to 15 minutes. So the queue runs the full set.Enabling the queue
This PR only adds the trigger and does not change behaviour by itself. A maintainer adds the merge queue rule to the
mainruleset separately. After that,gh pr mergeadds a pull request to the queue instead of merging it immediately.Validation
pytest -q tools/ci/tests/test_required_ci.py tools/ci/tests/test_public_tree.py tools/ci/tests/test_release_contract.py: 228 passedpython tools/ci/check_public_tree.py: passedactionlint(1.7.7, with the policy job's ignore): cleanruff format --check tools/ciandruff check --select E,F,I,UP,B tools/ci: cleanSummary by CodeRabbit