From 33e17dba0ee2160c0b711c5a47e4b091d34021a4 Mon Sep 17 00:00:00 2001 From: glenn schrooyen Date: Sat, 19 Sep 2026 15:53:01 +0200 Subject: [PATCH] CI-9 follow-up: the summary said "mechanically", the blind spots say otherwise The residual-risk paragraph at the top of checks.yml claims the `guard the trigger` step "keeps it that way mechanically rather than by asking the next editor to read this comment". For blind spots 1 and 3 that is not true: the guard lives inside the workflow a filter makes Gitea skip, so for those cases the defence IS the comment. That paragraph is the preamble someone reads at the exact moment they are editing the trigger, so a summary running ahead of its detail is worse here than elsewhere. It now points at the blind spots and states spot 3 plainly: a filter naming a branch nothing targets is itself skipped, lands green and untested, and then skips every subsequent pull request - the gate off for everything, silently. Flagged by the reviewer on PR #95 (issuecomment-1424) as non-blocking. This PR is also the first real test of CI-9's fix on release/1.0 itself. Run 806 was a workflow_dispatch and posts no commit status at all, so it verified content but never the gate. This one has to post `checks / unit (pull_request)` as success rather than skipped. Verified before push: the guard passes against this edited file (whose new prose quotes `branches: [main]` and `master`) and still refuses a genuine filter added to the `on:` block. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU --- .gitea/workflows/checks.yml | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/.gitea/workflows/checks.yml b/.gitea/workflows/checks.yml index 425738e..0d7d692 100644 --- a/.gitea/workflows/checks.yml +++ b/.gitea/workflows/checks.yml @@ -110,6 +110,18 @@ name: checks # trigger` step below then keeps it that way mechanically rather than by asking # the next editor to read this comment. # +# ⚠️ READ THE BLIND SPOTS ON THAT STEP BEFORE TRUSTING THE SENTENCE ABOVE. +# "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. +# # 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]`, # `[no ci]`, `[skip actions]`, `[actions skip]`) does NOT behave like a filter