WIP: the gate must not print PASS when a stage was skipped

INCOMPLETE — preserved by the PM after the authoring agent hit the session
rate limit mid-task. Do not merge without finishing and gating it.

Problem: in ci/gate.sh a FAILED stage sets BLOCK=1 but a SKIPPED stage only
warns, so the gate prints the words 'not green' and then concludes
'MERGE GATE: PASS' and exits 0. Observed live tonight with prom-rules, and
independently with l0 when the pinned kyverno CLI was absent. That is
fail-open in the one component whose whole job is to fail closed.

The agent was mid-way through adding truthy/strict_skips helpers to ci/lib.sh.

WHAT REMAINS:
  - Per-stage justification for which skips must BLOCK and which may degrade
    to a non-zero UNDECIDED (spec-immutability and L2/L3 skip for legitimate
    environmental reasons and must stay usable locally).
  - Whether CI and local can be distinguished reliably here.
  - New ci/tests/ suite for the decision logic, and a before/after proof.
  - Reconciling with the unmerged branch fix/touched-requirements-fail-closed,
    whose 47068ee already makes an unusable touched subset block, and whose
    56c242d claims 255 of 476 paths were unmapped in the path->requirement
    map — a far larger fail-open that still needs measuring on current main.

Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
jakman85andClaude Opus 5 committed 2026-09-13 16:08:11 -05:00
1 parent f4f6e5f7a3
commit 63bc890261
2 files changed
+171 -8

No files matched your search

+35
View File
@@ -84,6 +84,41 @@ cluster_available() {
esac
}
# truthy <value> — the ONE place the repo's "is this switch on" spelling lives, so
# CLUSTER_AVAILABLE / REQUIRE_CLUSTER_TESTS / REQUIRE_SPEC_VERIFICATION / GATE_STRICT_SKIPS
# all agree. Anything not listed is OFF: a misspelled value never turns a guard ON.
truthy() {
case "${1:-}" in
true|TRUE|True|1|yes|YES|y|on|ON) return 0 ;;
*) return 1 ;;
esac
}
# --- Skip strictness: is this a CI runner, or a workstation? -------------------
# A SKIPPED stage is never green anywhere (HARD RULE 4), but its SEVERITY differs:
#
# CI the pinned toolchain is installed by .gitea/workflows/scripts/install-tools.sh
# before the gate runs, and every seam is on `main`. A stage that skips here is a
# DEFECT (a tool dropped from the installer, a seam that went unwired) -> BLOCK.
# local a missing pinned tool is a real, ordinary local condition -> the gate reports
# UNDETERMINED (exit 3): not green, not a pass, but distinguishable from a red.
#
# HOW CI IS DETECTED, AND WHY A WRONG ANSWER CANNOT FAIL OPEN. GITHUB_ACTIONS / CI are set
# by the Actions runner ITSELF (Gitea's act_runner sets both, as does GitHub) — we do not
# sniff hostnames, paths or tool availability, because a heuristic that guesses "this looks
# like CI" is exactly the kind of unreliable inference this gate must not contain. If
# detection is WRONG in either direction the gate still refuses to pass: a CI run misread as
# local yields UNDETERMINED, which is non-zero and fails the job all the same; the only thing
# lost is the harsher BLOCKED label. Override explicitly with GATE_STRICT_SKIPS=true|false
# (e.g. to rehearse CI strictness locally).
: "${GATE_STRICT_SKIPS:=auto}"
strict_skips() {
case "$GATE_STRICT_SKIPS" in
auto) truthy "${GITHUB_ACTIONS:-}" || truthy "${CI:-}" ;;
*) truthy "$GATE_STRICT_SKIPS" ;;
esac
}
mkartifacts() { mkdir -p "$JUNIT_DIR" "$COVERAGE_DIR"; }
# --- Offline (L0/L1) per-check step summary -----------------------------------