Read from the API rather than inferred. gh api repos/Gitlawb/node/rulesets/15718554 returns these
rules on main:
deletion, non_fast_forward, update, required_linear_history,
copilot_code_review,
pull_request (required_approving_review_count: 1)
merge_queue (grouping_strategy: ALLGREEN)
There is no required_status_checks rule. gh api repos/Gitlawb/node/branches/main/protection
returns 404, so classic branch protection is unused and the ruleset is the whole gate.
The mismatch is between the last two lines. merge_queue is configured with ALLGREEN grouping,
which decides how the queue batches entries by their check results, while nothing in the ruleset
requires any check to exist or pass. So the strategy is grouping on a signal the ruleset never
demands.
What this does and does not mean
AGENTS.md:43 already records the underlying state plainly:
The main branch ruleset currently requires one approving review but does not require these checks
to pass before merge; a failing job should block review approval in practice, but nothing enforces
that mechanically today.
So the state is known and deliberate. What is filed here is narrower and, as far as I can tell,
unrecorded: the merge queue's grouping strategy presumes required checks that are not configured.
Two consequences worth deciding on rather than leaving implicit:
- A red PR can merge if a reviewer approves without reading the checks. That is the documented state
and is a policy choice.
- The
ALLGREEN grouping is doing less than its name suggests, because "all green" is evaluated
against whatever checks happen to report, not against a required set. A PR that reports no checks
at all is trivially all-green.
The second point is the one that seems more likely to surprise someone later.
Related, and why this is separate
Surfaced while checking a different claim, that a fork PR could redefine the workflow gating it.
That claim is refuted on its own terms: .github/workflows/pr-checks.yml:3-21 triggers on
pull_request and not pull_request_target, so a fork run carries no secrets and a read-only token,
and merged PR #107 deliberately added the workflow-change label that flags fork PRs touching
.github/workflows/ (pr-triage.yml:67-68). Do not conflate pr-checks.yml with pr-triage.yml,
which does use pull_request_target and whose header explains that it never checks out PR head code.
But the refutation leans on a human reviewer noticing the label, and that reviewer is the only gate
precisely because no checks are required. Hence this issue rather than that one.
#234 (npm-publish trusted publishing has no environment or branch gate) is the nearest neighbour and
is a different surface: publish privilege on workflow_dispatch, not merge-time check integrity.
Fix direction
Decide deliberately, since either answer is defensible:
- Add a
required_status_checks rule naming the jobs that must pass, which makes ALLGREEN mean what
it reads as and closes the red-merge path.
- Or keep review-only merging and drop or re-tier the
ALLGREEN grouping so the configuration stops
implying an enforcement that is not there.
If the first, note the checks must be named as they appear in the merge-queue context, and
pr-checks.yml already runs in merge_group, so the jobs exist to require.
Read from the API rather than inferred.
gh api repos/Gitlawb/node/rulesets/15718554returns theserules on
main:There is no
required_status_checksrule.gh api repos/Gitlawb/node/branches/main/protectionreturns 404, so classic branch protection is unused and the ruleset is the whole gate.
The mismatch is between the last two lines.
merge_queueis configured withALLGREENgrouping,which decides how the queue batches entries by their check results, while nothing in the ruleset
requires any check to exist or pass. So the strategy is grouping on a signal the ruleset never
demands.
What this does and does not mean
AGENTS.md:43already records the underlying state plainly:So the state is known and deliberate. What is filed here is narrower and, as far as I can tell,
unrecorded: the merge queue's grouping strategy presumes required checks that are not configured.
Two consequences worth deciding on rather than leaving implicit:
and is a policy choice.
ALLGREENgrouping is doing less than its name suggests, because "all green" is evaluatedagainst whatever checks happen to report, not against a required set. A PR that reports no checks
at all is trivially all-green.
The second point is the one that seems more likely to surprise someone later.
Related, and why this is separate
Surfaced while checking a different claim, that a fork PR could redefine the workflow gating it.
That claim is refuted on its own terms:
.github/workflows/pr-checks.yml:3-21triggers onpull_requestand notpull_request_target, so a fork run carries no secrets and a read-only token,and merged PR #107 deliberately added the
workflow-changelabel that flags fork PRs touching.github/workflows/(pr-triage.yml:67-68). Do not conflatepr-checks.ymlwithpr-triage.yml,which does use
pull_request_targetand whose header explains that it never checks out PR head code.But the refutation leans on a human reviewer noticing the label, and that reviewer is the only gate
precisely because no checks are required. Hence this issue rather than that one.
#234 (npm-publish trusted publishing has no environment or branch gate) is the nearest neighbour and
is a different surface: publish privilege on
workflow_dispatch, not merge-time check integrity.Fix direction
Decide deliberately, since either answer is defensible:
required_status_checksrule naming the jobs that must pass, which makesALLGREENmean whatit reads as and closes the red-merge path.
ALLGREENgrouping so the configuration stopsimplying an enforcement that is not there.
If the first, note the checks must be named as they appear in the merge-queue context, and
pr-checks.ymlalready runs inmerge_group, so the jobs exist to require.