merge-gate: prFromHeadRef rejects a queue ref whose base branch contains a slash #655

Reproduce

A merge queue whose base branch name contains a slash yields a merge_group head ref of the shape refs/heads/gh-readonly-queue/release/1.0/pr-<N>-<sha>. prFromHeadRef in .github/scripts/merge-gate.mjs matches the base as a single segment:

const m = /^gh-readonly-queue\/[^/]+\/pr-(\d+)-([0-9a-f]{7,40})$/i.exec(branch)

release/1.0 is two segments, so the function returns null and the job throws cannot read a pull request from head_ref "…". The multi-segment shape follows from the queue's naming rule — gh-readonly-queue/<base>/pr-<N>-<sha>, with the base branch name embedded as-is — not from an observed run: run 39694988559, which the file cites, is gh-readonly-queue/main/pr-626-6438cb2b…, a single-segment base, and it failed on the refs/heads/ prefix instead. No run in this repository has exercised a slash in the base yet; only the base is assumed to be one segment.

What should happen

prFromHeadRef resolves any queue base, including a multi-segment one — release/1.0 → { pr: 652, sha: 'abc1234' } — while keeping today's refusals for refs/heads/main, refs/tags/… and a non-hex tail. A greedy base match plus the two shapes as tests.

Impact today

None, and it fails closed: the job throws and rejects, it never reads the ref as "no objection". Only main has a merge queue (main merge queue, ruleset 25173372), so every real ref is single-segment today. "Dormant" describes that: no queue uses a slash yet — not a reason to postpone the fix, because the first such queue would be refused end to end (see Status).

Scope

prFromHeadRef and its test file only; no change to the single-segment main behaviour.

Status

Tracked by the external author's pull request #717 (rahul05ranjan, tip dc83a0fc). The owner decision (2026-10-22, Chief) is that it should land now: the change only widens the base segment from [^/]+ to .+, it is a no-op for the single main merge queue that exists today, its refusals are pinned by 32/32 cases, and leaving it out means the first release/x queue is refused end to end with no one noticing in advance.

It is blocked on one sentence, not on code: the pull request still cites run 39694988559 as evidence for a multi-segment base, and that run is gh-readonly-queue/main/pr-626-6438cb2b… — single-segment, failed on the refs/heads/ prefix. The replacement wording is in a comment on #717; the author has to push the new tip, and a PASS then has to be re-judged on it.

Do not fold this into #640 — a new commit there would void that tip's PASS.

Written-by: Triage