ci: support merge queues

[Charlesthebird]

---

🤖 written by Claude (start)

Release note

NONE

Changes

• CI checks now run on the merge_group event, so a merge queue can use them.
• The migration check and upgrade tests learn the base branch from the merge group, since github.base_ref is empty there.
• Merge queue runs share one Docker build cache instead of creating a new one each time.

Backports

• ci: support merge queues (backport to release/v0.10.x) #2712 to release/v0.10.x
• ci: support merge queues (backport to release/v0.9.x) #2713 to release/v0.9.x

---

🤖 written by Claude (end)

[Charlesthebird]

Follow-up: enable the merge queue

Needs repo admin.
Do this after merging.

1. Settings → Rules → Rulesets.
2. Open ruleset default.
3. Tick Require merge queue.
4. Set:

Setting	Value
Merge method	Squash and merge
Build concurrency	5
Minimum group size	1
Maximum group size	5
Wait time	5 minutes
Status check timeout	60 minutes
All entries must pass	On

5. Keep required status checks.
6. Turn off "up to date".
7. Save.
8. Queue one small PR.
9. Confirm it merges alone.

Release branches: merge #2712 and #2713 first.
Then repeat on ruleset 0.x.
Drop its required DCO check.
It never reports on merge groups.

---

🤖 written by Claude

[Charlesthebird]

This automated review is a first pass. A manual review will follow once the blockers are addressed.

---

Nothing blocks merge. Every check the main ruleset requires runs on merge_group, and the two places that read the PR base branch resolve it inside a queue. The queue itself still has to be switched on; the follow-up comment has the steps.

✅ What I checked

• ✅ All 11 required contexts in ruleset default are job ids in ci.yaml, with no name: overrides, and the build and python-test matrices produce the parenthesised names in the list.
• ✅ ci.yaml leaves merge_group: without paths-ignore, so a docs-only group still reports the required checks instead of hanging the queue.
• ✅ The concurrency group falls through to github.ref, which is unique per group and carries event_name, so PR and queue runs never cancel each other.
• ✅ origin/<base> exists in a fetch-depth: 0 checkout because actions/checkout fetches +refs/heads/*:refs/remotes/origin/*, and the merge base against it is the queued PR's parent on main.
• ✅ Both ${{ github.base_ref || github.event.merge_group.base_ref }} fallbacks return the old value on pull_request, push and workflow_dispatch, since the refs/heads/ strip is a no-op on a bare branch name.
• ✅ scripts/prev-stable-version.sh receives CURRENT_REF, so it no longer re-derives the base branch from the empty GITHUB_BASE_REF.
• ✅ The push triggers in ci.yaml and image-scan.yaml filter to main and release/**, so the queue's gh-readonly-queue/ branch does not fire them a second time.
• ✅ The two pull_request_target labelers, image-scan, tag and stalebot never run on a merge group and are not required checks.
• ✅ A repo-wide grep for pull_request, head_ref, base_ref, GITHUB_REF and github.event finds no other reader of PR-only context.

Findings, all fixed on the branch

• upgrade-test-setup derived its base branch from GITHUB_BASE_REF, empty in a queue, so release-branch groups ran the wrong upgrade legs. Fixed in 5cc9a8a.
• prev-stable-version.sh re-derived the same value on its own, which undid the action's fix on release/**. Fixed in fa99e2a.
• BRANCH_CACHE_KEY used the group's unique ref name, so every group wrote twelve buildx cache scopes nothing reads again. Fixed in fa99e2a.
• The base_ref fallback in migration-immutability.yaml had no comment explaining the refs/heads/ strip. Fixed in fa99e2a.

---

🤖 written by Claude