[abrichr]

Why

A merge queue only works if every required check reports on merge_group events; otherwise each group waits forever. Batching (up to 5 PRs per group) turns 5 serial "update branch, rerun everything, merge" cycles into one tested group.

Separately, dependency-review and CodeQL ran only on PRs into main. Stacked PRs therefore reached main without those required checks and showed BLOCKED (#1358).

What changes

merge_group triggers on Python CI, Packages, Secret Scan, Dependency Review, CodeQL and Platform manifest. These cover every required check: gitleaks, dependency-review, Analyze (python), run-ci (ubuntu-latest, 3.12) and packages-gate.

Scoping a group like a push to main.

• Packages' scope job and desktop-build's artifact-scope diff the group's head against github.event.merge_group.base_sha.
• Packages then runs the full Python/OS matrix (the PR tier runs one lane after #1410), but only for the packages the group touches.
• The Desktop build classifier treats merge_group like push: native installers build only for artifact-sensitive changes.
• If the base can't be read, both fall back to running everything.

dependency-review in a group. It passes the group's base_sha and head_sha explicitly, since a group's payload has no pull request.

Every PR base. pull_request on dependency-review and CodeQL no longer filters to main.

Settings this PR does not change

These need a repository admin. In the main branch ruleset, under "Require merge queue":

Setting	Value
Merge method	Merge
Maximum pull requests to build	5
Minimum pull requests to merge	1
Wait time to meet minimum group size	5 minutes
Only merge non-failing pull requests	on
Status check timeout	60 minutes
Required checks	unchanged; GitHub applies them to the group

Merge this PR before turning the queue on. Otherwise groups wait on checks that never start.

Savings

Today each PR runs its full pipeline about twice: once on the PR, and again after "update branch" when main has moved. That's about 40 jobs per run.

With batching, up to 5 PRs share one group run instead of 5 rebase-and-rerun cycles: about 4 × 40 = 160 jobs saved per full group of 5.

Groups also replace the serial merge wait. In the batch of 2026-10-19, rebases on main added hours of queue time.

I'll add measured group wall times as a comment once the queue is on.

Verified

• Seven workflows parse, and each has merge_group (desktop-build is a called workflow and inherits the event).
• Root workflow tests pass (112). Desktop tests pass (109), including a new test_merge_queue_group_is_scoped_like_main.

Follow-up (separate PR). A merge group's head commit becomes main's commit, so the push run on main repeats the group's run on the same tree. Once the queue is on, main runs can be cut to what the Desktop release gate needs. That needs coordinating with the session moving the release trigger to workflow_run.

🤖 Generated with Claude Code