Skip to content

THROWAWAY: verify branch protection blocks a red PR (DELETE ME) - #61

Merged
wshallwshall merged 1 commit into
mainfrom
throwaway/verify-branch-protection-DELETE-ME
Jul 30, 2026
Merged

THROWAWAY: verify branch protection blocks a red PR (DELETE ME)#61
wshallwshall merged 1 commit into
mainfrom
throwaway/verify-branch-protection-DELETE-ME

Conversation

@wshallwshall

Copy link
Copy Markdown
Collaborator

Do not merge. Do not review. This PR exists to prove the 2026-07-29 branch-protection change actually blocks a failing PR, and will be closed as soon as it has.

It carries one deliberately failing test, so the three required test (…) contexts must go red and the merge must be refused. Verifying "the PUT returned 200" is not verifying the gate works.

@wshallwshall
wshallwshall merged commit a8886f2 into main Jul 30, 2026
29 of 32 checks passed
@wshallwshall
wshallwshall deleted the throwaway/verify-branch-protection-DELETE-ME branch July 30, 2026 01:00
wshallwshall added a commit that referenced this pull request Jul 30, 2026
) (#62)

Reverts a8886f2. I merged a deliberately-failing test into main while verifying
the new branch protection, and that is entirely my error.

WHY IT MERGED: `enforce_admins: false`, which was enabled minutes earlier by
owner decision to keep an escape hatch for a runner outage. Admin bypass does
exactly what it says -- the merge API honoured it for the owner token, so the red
required check did not stop the merge. The gate itself was working and reported
`mergeable_state: "blocked"` correctly, both while checks were pending and after
`test (ubuntu-latest, py3.14)` went to `failure`.

WHY THE VERIFICATION WAS WRONG: "attempt a merge and confirm it is refused"
cannot be run by a caller holding admin bypass. The refusal I was testing for is
one that applies to non-admins, so the only outcomes were a merge succeeding
(what happened) or a false sense of security if it had failed for some unrelated
reason. `mergeable_state: "blocked"` was the correct and sufficient evidence and
I already had it. I designed a test whose result could not mean what I wanted it
to mean, on the same day and in the same session as flagging that class of error
half a dozen times.

The two verifications that DID hold, and were the ones that mattered:

  * the live protection object re-read after the write -- 12 contexts,
    strict:true, enforce_admins:false, and every field I intended to PRESERVE
    still intact (this endpoint replaces the whole object, so the body was
    derived from the live GET with each carried-over field asserted, never
    hand-written);
  * `comm -23` between the 12 required names and the names that ACTUALLY RUN on a
    real PR head is empty, so no required context is unsatisfiable -- the trap the
    vault repo fell into, where 10 required contexts come from disabled workflows
    and no PR can ever merge.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant