From 6e2bec140cb197c61e162f1d06799d249ec35544 Mon Sep 17 00:00:00 2001 From: antoinetoussaint-byte Date: Wed, 4 Nov 2026 13:44:39 -0500 Subject: [PATCH] ci: the boundary gate reports on merge-queue entries, so it can be required Measured on #1303: with `boundaries` added as a required status check, the merge-queue entry sat in AWAITING_CHECKS with every other required context already green. `boundaries` was the one context absent from the queue head, because this workflow fired only on `pull_request` and `push`. A required context that never reports on a queue entry strands the pull request until the check-response timeout ejects it. `go.yml` already carries `merge_group` with a comment saying exactly this. This brings the boundary gate to the same footing so the requirement can be put back on the ruleset, where the gate actually binds rather than merely reports. Co-Authored-By: Claude Opus 5 --- .github/workflows/boundaries.yml | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/.github/workflows/boundaries.yml b/.github/workflows/boundaries.yml index 081eb28ac..357eec295 100644 --- a/.github/workflows/boundaries.yml +++ b/.github/workflows/boundaries.yml @@ -7,6 +7,15 @@ on: pull_request: push: branches: [main] + # The merge queue builds each entry on a `gh-readonly-queue/main/...` branch + # and fires `merge_group`, not `pull_request`. Without this trigger this gate + # never reports on a queued entry, so making it a required context strands + # every pull request in the queue until the check-response timeout ejects it. + # Measured on #1303: `boundaries` was the one required context absent from + # the queue head, and the entry sat in AWAITING_CHECKS while every other + # check had already passed. `go.yml` carries the same trigger for the same + # reason. + merge_group: permissions: contents: read