Phase 2 of the Mergify rollout (#410) - enable batching, now that Phase 1 (serial queue) is proven end-to-end (mergify[bot] merged #425/#426 and serialised #426 -> #427 with an update + re-CI).
What changes
queue_rules.default.batch_size: 1 -> 5 + batch_max_wait_time: 5 min. Mergify now validates up to 5 queued PRs together on ONE speculative branch (latest main + the batch), runs CI once, and merges the whole batch if green - roughly 5x the serial throughput.
All other semantics unchanged: merge commits, "CI passed" the single required check, P0-P9 priority, auto_merge_conditions trigger.
The require-up-to-date swap (paired ruleset change)
Batching is incompatible with GitHub's "Require branches to be up to date before merging", so that option is turned off in the main ruleset (strict_required_status_checks_policy: false; the required CI passed check stays). This does not drop the invariant - it relocates it: the speculative batch branch is latest-main-plus-the-batch, so a green batch check is the against-latest-main test. Sanctioned swap, authorized because Phase 1 proved the queue performs that update + re-CI.
Rollout order
Ruleset flipped first (the serial queue still guards the invariant while main still has batch_size 1), then this PR merges -> batching live.
Phase 2 of the Mergify rollout (#410) - enable **batching**, now that Phase 1 (serial queue) is proven end-to-end (mergify[bot] merged #425/#426 and serialised #426 -> #427 with an update + re-CI).
## What changes
- `queue_rules.default.batch_size: 1 -> 5` + `batch_max_wait_time: 5 min`. Mergify now validates up to 5 queued PRs together on ONE speculative branch (latest `main` + the batch), runs CI once, and merges the whole batch if green - roughly 5x the serial throughput.
- All other semantics unchanged: merge commits, "CI passed" the single required check, P0-P9 priority, `auto_merge_conditions` trigger.
## The require-up-to-date swap (paired ruleset change)
Batching is incompatible with GitHub's "Require branches to be up to date before merging", so that option is turned **off** in the `main` ruleset (`strict_required_status_checks_policy: false`; the required **CI passed** check stays). This does **not** drop the invariant - it relocates it: the speculative batch branch *is* latest-main-plus-the-batch, so a green batch check **is** the against-latest-main test. Sanctioned swap, authorized because Phase 1 proved the queue performs that update + re-CI.
## Rollout order
Ruleset flipped first (the serial queue still guards the invariant while `main` still has batch_size 1), then this PR merges -> batching live.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Phase 2 of the Mergify rollout (#410) - enable batching, now that Phase 1 (serial queue) is proven end-to-end (mergify[bot] merged #425/#426 and serialised #426 -> #427 with an update + re-CI).
What changes
queue_rules.default.batch_size: 1 -> 5+batch_max_wait_time: 5 min. Mergify now validates up to 5 queued PRs together on ONE speculative branch (latestmain+ the batch), runs CI once, and merges the whole batch if green - roughly 5x the serial throughput.auto_merge_conditionstrigger.The require-up-to-date swap (paired ruleset change)
Batching is incompatible with GitHub's "Require branches to be up to date before merging", so that option is turned off in the
mainruleset (strict_required_status_checks_policy: false; the required CI passed check stays). This does not drop the invariant - it relocates it: the speculative batch branch is latest-main-plus-the-batch, so a green batch check is the against-latest-main test. Sanctioned swap, authorized because Phase 1 proved the queue performs that update + re-CI.Rollout order
Ruleset flipped first (the serial queue still guards the invariant while
mainstill has batch_size 1), then this PR merges -> batching live.Merge Protections
🟢 All 2 merge protections satisfied — ready to merge.
Show 2 satisfied protections
🟢 📃 Configuration Change Requirements
Mergify configuration change
check-success = Configuration changed🟢 🚦 Auto-queue
When all merge protections are satisfied and these conditions match, this pull request will be queued automatically.
-conflict-draftbase = maincheck-success = CI passedlabel != brokenMerge Queue Status
2026-07-08 12:34 UTC· Rule:default· triggered by merge protections2026-07-08 13:01 UTC· at68e45df0ea44cc65e1493b4854c2b2035628d4df· mergeThis pull request spent 26 minutes 36 seconds in the queue, including 26 minutes 21 seconds running CI.
Required conditions to merge
-conflict-draftbase = maincheck-success = CI passedgithub-review-approved[🛡 GitHub repository ruleset rulemain]label != brokencheck-success = Debug buildcheck-neutral = Debug buildcheck-skipped = Debug buildcheck-success = Unit testscheck-neutral = Unit testscheck-skipped = Unit testscheck-success = CI passedcheck-neutral = CI passedcheck-skipped = CI passedmain]:check-success = @github-actions/CI passedcheck-neutral = @github-actions/CI passedcheck-skipped = @github-actions/CI passed