Merge gate is not a required check on the merge queue, so a red gate does not block a merge

Summary

Merge gate runs and refuses correctly, but nothing requires it, so a red gate does not stop a merge. On 2026-10-21 it ran on merge_group twice and failed both times, and the queue merged anyway:

When (UTC)	Event	head	Merge gate
12:48:17Z	`merge_group`	`21b12e25`	failure
12:50:11Z	`merge_group`	`fe79de66`	failure

#632 was merged at 12:52:09Z as fe79de66, three minutes after an INC had been posted on the same sha (b99d6052) — and with the gate red.

Root cause

main merge queue (ruleset 25173372) lists exactly two required status checks:

ubuntu-latest · Node 24 · DSH 0.2.0-rc.2
tests-ok

Merge gate is not one of them. The workflow (.github/workflows/merge-gate.yml) triggers on merge_group and .github/scripts/merge-gate.mjs exits non-zero when the newest verdict at the head is INC/REQUEST_CHANGES or missing — none of which matters while the queue ruleset does not wait for it.

Expected behaviour

Merge gate is a required status check on main merge queue (integration id 15368), next to tests-ok, so a failing gate blocks the queue entry instead of merely colouring it red.

Scope

Settings only, no code. Adding a required check is a ruleset change and needs admin rights on the repository; nothing in this repository can make the gate binding. The related code defects (a verdict that does not begin with Verdict: is invisible; the AGENTS.md sentence lost its second half) are #637.

Blocked on

The owner / repository admin: edit main merge queue → required status checks → add Merge gate. Until then every merge relies on a human re-reading the newest verdict, which is what failed twice today (#610 and #632).

Evidence

Actions runs for merge_group on 2026-10-21: 12:48:17Z and 12:50:11Z, both failure.
Merge of #632 at 12:52:09Z (fe79de66), with an INC posted at 12:49Z on the same sha.
Ruleset 25173372 (main merge queue): required checks = the two listed above.

Written-by: Triage

Scope note: this issue is the only part of the #637 failure that is not code — a required status check is repository settings (main merge queue, ruleset 25173372), and nothing in the repository can make the gate binding.

Blocked on: the owner / repository admin — ruleset → required status checks → add Merge gate (integration id 15368), next to tests-ok and ubuntu-latest · Node 24 · DSH 0.2.0-rc.2.

While this stays open, a red Merge gate only colours the merge red: the queue still lands the PR, so every merge depends on a human re-reading the newest verdict — which is exactly what failed on #610 and #632.

The code half (line-anchored verdict, the AGENTS.md sentence) is #637 and is agent-ready.

Done, on the owner's word (2026-10-21): Merge gate is now a required status check on the merge queue.

What changed: ruleset main merge queue (25173372), required_status_checks went from

ubuntu-latest · Node 24 · DSH 0.2.0-rc.2   (integration 15368)
tests-ok                                    (integration 15368)

to the same two plus:

Merge gate                                  (integration 15368)

Read back after the write (PUT 200), so this is the stored state, not the request. Everything else in the ruleset is untouched: merge_method SQUASH, grouping_strategy ALLGREEN, max_entries_to_build 1, check_response_timeout_minutes 60.

Why it mattered: all four merge_group runs on 2026-10-21 were failure — 12:39:03Z (7a630732), 12:41:07Z (cf69be8d), 12:48:17Z (21b12e25), 12:50:11Z (fe79de66) — and every one of those SHAs reached main anyway. The judgement was live and refusing; nothing was obliged to obey it.

One consequence worth stating before it surprises anyone: until #637 lands the row-anchored verdict parsing, a queue entry whose newest conclusive text is not a first-line Verdict: will now be refused instead of merged. That is the intended direction of this change, and it is why #637 is the next thing Dev ships.

Written-by: Chief

Rolled back: Merge gate removed from required checks (ruleset 25173372).

Readback after the update: ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 | tests-ok only.

Why: .github/workflows/merge-gate.yml only runs on merge_group, so a PR head never reports Merge gate. With it required, every open PR flipped to blocked and could not even enter the queue:

#626 00fa1859 — back to clean
#634 538d97ed — back to clean (still on hold, unrelated)
#611 4da46bff — back to clean
#636 06bc70ac — still blocked; its failures (tests-ok, plugins (tree), ubuntu-latest · Node 24) are its own and are not caused by this ruleset change.

Re-adding the required check needs both of these, or the same regression returns:

merge-gate.yml produces the same check name on pull_request and merge_group (report on the PR, adjudicate in the queue).
Merge gate is visible in the checks list of a real PR head, not only present as a workflow file.

The gate still does not stop a merge (#637); this only restores the queue.

Run the merge gate on pull_request too, as a report

Reopened — the close is older than the rollback (closed at 14:11:16Z as completed; rolled back at 14:20:27Z). The requirement here is still unmet: Merge gate is not among the required checks of main merge queue (ruleset 25173372); the readback after the rollback is ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 | tests-ok only.

Both prerequisites from the last comment now exist on #640 at a55ccc5c (PASS, 9/9 green): merge-gate.yml produces the same Merge gate check on pull_request and on merge_group, and a real PR head carries it.

The order is not free. The queue job checks out merge_group.base_sha, so a queue entry runs main's copy of merge-gate.mjs. Main's copy (a5a887b9) rejects every queue ref — prFromHeadRef expects a bare gh-readonly-queue/... while the event carries refs/heads/gh-readonly-queue/... — so with the check required, every entry would go red and the queue would stop globally.

Sequence:

merge Read the verdict from its first line, and test the merge gate through its own entry point #640 (its own queue entry runs the old base copy and shows red there; not blocking, because this check is not required yet);
read main's merge-gate.mjs and confirm prFromHeadRef accepts both spellings;
add Merge gate (integration id 15368) to the required checks of ruleset 25173372;
read the ruleset back;
prove it stops a merge with a deliberately-INC PR — no queue entry has ever been judged so far (runs 39602546475, 39602806953, 39653640861, 39694988559, 39696278650 all failed on that parse).

Blocked on: owner/admin action at steps 1 and 3–5. The code side is done on #640.

Written-by: Triage

Read the verdict from its first line, and test the merge gate through…

Both prerequisites from the rollback comment are now true on main — this issue is one ruleset step away, not blocked on code.

Read the verdict from its first line, and test the merge gate through its own entry point #640 merged at 00:33:24Z (merge commit d105f222): the verdict is read from the first line, and merge-gate.yml produces the same Merge gate check on pull_request and on merge_group, so a real PR head carries it.
Judge a merge-queue entry at its pull request head, not at the queue base #658 merged at 01:03:18Z (merge commit c74e1207): queue mode now judges the pull request's live head instead of the <sha> in gh-readonly-queue/<base>/pr-<N>-<sha>, which is the entry's base. Every earlier merge_group run refused for exactly that reason (run 39701316520 on Declare DSH_SECRETS_WITHHELD so a withheld turn keeps its shell #654: "head moved to ad0c471 after this entry was built at d105f22").

So neither failure mode that forced the 14:20:27Z rollback remains: the check exists on PR heads, and the queue adjudicates.

Remaining, in this order:

one real queue entry whose merge_group run reports a green Merge gate — the next PR that enqueues produces it, since the check is not required yet and nothing blocks the entry;
add Merge gate (integration_id 15368) to the required checks of ruleset 25173372;
read the ruleset back;
prove it stops a merge with a deliberately-INC PR — no queue entry has ever been refused by a working gate so far.

Steps 2–4 are owner work. One agent-ready issue crossed off the ruleset side? None: #655 stays separate — prFromHeadRef on main still matches the base as [^/]+, so a multi-segment base (release/1.0) would still be rejected; dormant while main is the only queue.

Written-by: Triage

feat(scripts): refuse to enqueue a held or unpassed pull request (#602)…

Write the mechanical T2/T3 merge gates into AGENTS.md and autonomous-…

Closed as completed: the ruleset step this issue was waiting on is done.

GET /repos/ThinkFlowLab/FlyBot/rulesets/25173372 (main merge queue, active) now lists three required status checks, all with integration_id 15368:

{"context":"ubuntu-latest · Node 24 · DSH 0.2.0-rc.2"}
{"context":"tests-ok"}
{"context":"merge-gate"}

merge-gate is the job name the workflow produces on both pull_request and merge_group, so a red gate now blocks the queue entry, which is exactly what the body asked for. bypass_actors stays empty and the merge-queue parameters are unchanged (SQUASH, one entry, ALLGREEN).

No code changed in this closing step; the workflow-side parts landed earlier in #640 and #658.

Written-by: Triage

Read the body on a queue entry, and write enqueue-guard on merge_group (

Navigation Menu

Repository navigation

`Merge gate` is not a required check on the merge queue, so a red gate does not block a merge #639

Summary

Root cause

Expected behaviour

Scope

Blocked on

Evidence

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Merge gate is not a required check on the merge queue, so a red gate does not block a merge #639

Description

Summary

Root cause

Expected behaviour

Scope

Blocked on

Evidence

Activity

Birfy commented on Oct 21, 2026

Birfy commented on Oct 21, 2026

Birfy commented on Oct 21, 2026

Birfy commented on Oct 22, 2026

Birfy commented on Oct 22, 2026

Birfy commented on Oct 22, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`Merge gate` is not a required check on the merge queue, so a red gate does not block a merge #639