[ixuz]

What and why

Runs that start together share 20 runners, and in a busy merge queue many runs are ones nobody needs. Each release commit moves main under the queue, and GitHub builds every queued pull request again on top of it. On 2026-11-04, 6.29.13 and 6.29.14 each sent the waiting pull requests back to the start. Each run that was replaced also kept going: CI's concurrency group was keyed on the ref, and every build of a queue entry gets a ref of its own. Run 41787567397 (pr-556-231080f24c) went on for 9 minutes after its rebuild, with most of its jobs not yet started. This branch does what #560 proposes, in two commits.

• The release waits for an empty queue. A new queue job in release.yml asks GitHub's GraphQL API how many entries the merge queue for main holds. It runs with a token that can only read, and with no secret, environment or checkout. The release job needs it, and a push run releases only when the count is 0. Once the last pull request leaves the queue, its push run releases every commit since the last tag as one version. A query that fails fails the run, instead of releasing or holding back without a word. A run by hand (workflow_dispatch) still releases main's tip whatever the queue holds. That is also how commits are released when the last entry fails or leaves the queue. The release job's environment, key and permissions are unchanged, and scripts/releaseWorkflow.test.ts holds that queue stays without secrets.
• A rebuild cancels the run it replaces. A merge_group run's concurrency group is now keyed on its merge commit's message (Merge pull request #<N> from …). Every build of one entry keeps that message, and no other entry has it: pr-556-231080f2, pr-556-ef7875bf and pr-556-44cddef0 all had the same one. Queue runs already cancel in progress. Pull request and main runs keep the groups they had, the release commit's own group included.
• Docs: releasing.md says when a release waits and what happens when the last entry fails. testing.md says how a rebuild cancels the run it replaced.

To watch on GitHub after merging. These can't be tested outside GitHub:

• The queue job's access. It should read the queue with contents: read. If its first run fails with "Resource not accessible by integration", it needs pull-requests: read too.
• The group name. A merge commit's message spans several lines, and GitHub should take it as a concurrency group name. If it doesn't, rebuilds go on as before, but nothing else changes.
• A small gap remains. A pull request that joins the queue between the count and the release push is still built again once.

Closes: #560