From 1b3e4191aff19287c9469b40fa310fc901f2c113 Mon Sep 17 00:00:00 2001 From: wshallwshall Date: Wed, 29 Jul 2026 20:01:34 -0500 Subject: [PATCH] revert: remove the throwaway protection-verification test from main (#61) Reverts a8886f2d. 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. --- .../test_zzz_protection_verification_DELETE_ME.py | 14 -------------- 1 file changed, 14 deletions(-) delete mode 100644 tests/test_zzz_protection_verification_DELETE_ME.py diff --git a/tests/test_zzz_protection_verification_DELETE_ME.py b/tests/test_zzz_protection_verification_DELETE_ME.py deleted file mode 100644 index ae4092f5..00000000 --- a/tests/test_zzz_protection_verification_DELETE_ME.py +++ /dev/null @@ -1,14 +0,0 @@ -# SPDX-License-Identifier: AGPL-3.0-or-later -# Copyright (C) 2026 MessageFoundry Organization and contributors -"""THROWAWAY — proves the 2026-07-29 branch-protection change actually BLOCKS a red PR. - -Delete this file and close its PR. It exists for one CI run. A protection change that returns HTTP -200 and blocks nothing is indistinguishable from one that works, so the only way to know is to make a -required context fail on purpose and watch the merge be refused. -""" - -from __future__ import annotations - - -def test_deliberate_failure_to_prove_required_checks_block_a_merge() -> None: - raise AssertionError("deliberate: verifying branch protection blocks a red PR")