Problem
The trunk ruleset uses strict_required_status_checks_policy (require branches up-to-date before merge), and auto-update-prs.yml rebases every behind PR on each trunk push. Together these serialize landings: each landing advances trunk, forcing every other open PR to rebase and re-run full CI before it can proceed. Landing N PRs therefore costs roughly O(N²) CI runs.
Observed on 2026-06-24: landing 7 patch/minor Dependabot PRs took ~40 CI complete runs (13 success, 7 failure, 20 cancelled); the tail PRs were retested 6–9× each.
PR #105 mitigates this (skip un-landable PRs in the sweep + group Dependabot to shrink N), but the underlying serialized rebase-and-retest cascade remains.
Proposed fix: GitHub merge queue
A native merge queue tests PRs together in batches against the projected post-landing trunk and lands them atomically when green:
- No manual rebase sweep —
auto-update-prs.yml's cascade can largely be retired.
- No "up-to-date" serialization cost — the queue handles ordering and batching → O(N) CI, not O(N²).
- A failing PR is dropped from the batch without re-testing the whole tail.
Considerations / open questions
- Ruleset change (owner decision): enable "Require merge queue" on the
trunk ruleset and set the required check to run in the merge_group context.
ci-complete.yml must also trigger on merge_group events (and report the required CI complete check there).- Reconcile with auto-merge:
--auto enqueues into the queue instead of landing directly — verify automerge.yml's flow and the agent-review gate still hold.
- Decide what remains of
auto-update-prs.yml (likely deletable once the queue handles freshness).
- Dependabot + merge queue interaction (grouped PRs,
@dependabot commands).
Acceptance
- Merge queue enabled on
trunk; required check runs in merge_group.
- Landing M green PRs costs ~M CI runs, not ~M².
- Agent-review gate and gate-integrity owner-approval semantics preserved.
Context: follow-up to PR #105; see also the cascade-waste analysis in that PR.
Problem
The trunk ruleset uses
strict_required_status_checks_policy(require branches up-to-date before merge), andauto-update-prs.ymlrebases every behind PR on each trunk push. Together these serialize landings: each landing advances trunk, forcing every other open PR to rebase and re-run full CI before it can proceed. Landing N PRs therefore costs roughly O(N²) CI runs.Observed on 2026-06-24: landing 7 patch/minor Dependabot PRs took ~40
CI completeruns (13 success, 7 failure, 20 cancelled); the tail PRs were retested 6–9× each.PR #105 mitigates this (skip un-landable PRs in the sweep + group Dependabot to shrink N), but the underlying serialized rebase-and-retest cascade remains.
Proposed fix: GitHub merge queue
A native merge queue tests PRs together in batches against the projected post-landing trunk and lands them atomically when green:
auto-update-prs.yml's cascade can largely be retired.Considerations / open questions
trunkruleset and set the required check to run in themerge_groupcontext.ci-complete.ymlmust also trigger onmerge_groupevents (and report the requiredCI completecheck there).--autoenqueues into the queue instead of landing directly — verifyautomerge.yml's flow and the agent-review gate still hold.auto-update-prs.yml(likely deletable once the queue handles freshness).@dependabotcommands).Acceptance
trunk; required check runs inmerge_group.Context: follow-up to PR #105; see also the cascade-waste analysis in that PR.