From 628279a68aca8d9197e0951b91f4d455f98b6d24 Mon Sep 17 00:00:00 2001 From: glenn schrooyen Date: Wed, 23 Sep 2026 20:18:50 +0200 Subject: [PATCH] CI-9 follow-up: name the filter that actually gets written, not the one that looks wrong Three sentences in the blind-spot clause went stale between writing and review. `no pull request in 99 has ever targeted master` is no longer true: SEC-2 made `release/1.0` -> `master` the mandated release path and protected `master` with the same required context, and a PR against that base has run for real. The census it came from also erases its own evidence - PR #102 was itself opened against `master` before retargeting, which the /pulls listing no longer shows, exactly as the caveat 25 lines above this clause warns. The clause also named `branches: [main]` as the hazard. That is the version that looks wrong. The one someone would actually write is `branches: [release/1.0]` - it reads as tightening onto the protected branch, every day-to-day PR keeps running green, and the only thing it switches off is the release PR whose content reaches an installed system. And the prescribed fix named only `release/1.0`'s status_check_contexts. Since SEC-2 `master` carries the same rule, so a reader following it literally would half-close the hole and believe it shut. Guard re-verified against the edited bytes: passes on this file (whose new prose quotes `branches: [release/1.0]` in a comment) and still refuses a real filter added to the `on:` block. Comment-only: 0 non-comment lines changed. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU --- .gitea/workflows/checks.yml | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/.gitea/workflows/checks.yml b/.gitea/workflows/checks.yml index 0d7d692..a7c3155 100644 --- a/.gitea/workflows/checks.yml +++ b/.gitea/workflows/checks.yml @@ -114,13 +114,25 @@ name: checks # "Mechanically" holds only for a reintroduced filter that still names the # PR's own base. For blind spots 1 and 3 the defence IS this comment, because # the guard lives inside the workflow that a filter makes Gitea skip. Blind -# spot 3 is the one that matters: a filter naming a branch nothing targets -# (`branches: [main]` from a template - this repo has no `main`, and no pull -# request in 99 has ever targeted `master`) is itself skipped, lands green and -# untested, and then every subsequent pull request is skipped too. That is the -# gate off for everything, silently. Closing it needs a SECOND permanently -# unfiltered workflow posting its own context, with that context added to -# `release/1.0`'s `status_check_contexts` - a forge change, with the owner. +# spot 3 is the one that matters: a filter naming a branch THIS pull request +# does not target is itself skipped, lands green and untested, and then every +# subsequent pull request matching it is skipped too. That is the gate off, +# silently. +# +# ⚠️ AND THE DANGEROUS ONE IS NOT `branches: [main]`, WHICH AT LEAST LOOKS +# WRONG. It is `branches: [release/1.0]`, which looks like tightening onto the +# protected branch and is what a careful person would write. Every day-to-day +# pull request still runs and still goes green, so nothing appears broken - +# and the only thing switched off is the `release/1.0` -> `master` release +# PR, i.e. the one whose content reaches an installed system. SEC-2 made that +# PR the mandated release path (docs/RELEASE.md), so this is now a live route +# rather than a hypothetical one. +# +# Closing it needs a SECOND permanently unfiltered workflow posting its own +# context, with that context added to the `status_check_contexts` of BOTH +# `release/1.0` AND `master` - both carry the rule since SEC-2, and adding it +# to one alone leaves the hole open on the other. A forge change, with the +# owner. # # THE MEASUREMENT, because the obvious guess is wrong and was nearly written # here as fact. A skip-ci keyword in a commit message (`[skip ci]`, `[ci skip]`,