3 Commits

Include renames

Author	SHA1	Message	Date
jakman85andClaude Opus 5	e993d0f7d1	docs(ci): the wiring comment named a secret Gitea cannot accept ... ci/gitea-settings.sh told the reader to "create a Gitea repo secret GITEA_SETTINGS_TOKEN". That instruction is IMPOSSIBLE to follow: Gitea reserves the GITEA_ prefix for secret names and rejects the PUT with HTTP 400 "invalid secret name". Same defect as the one fixed in PR #15 and in the README in PR #19 -- this was the third file carrying it, found by an agent reading the file rather than trusting my description of it. A comment that instructs an impossible action is not cosmetic: this exact wrong name is why the drift detector sat inert while a token existed and no secret did. Now names SETTINGS_API_TOKEN, and states explicitly that GITEA_SETTINGS_TOKEN remains honoured ONLY as a local-run env var -- it can never be the CI wiring, because the secret that would feed it cannot exist. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 19:30:35 -05:00
jakman85andClaude Opus 5	50a48e6f07	fix(ci): the settings token could NEVER have been stored -- Gitea reserves the GITEA_ prefix ... The drift detector merged in #11 was inert and would have stayed inert silently. WHAT HAPPENED. infra/gitea/set-ci-token.sh minted a token and PUT it to the repo Actions secret GITEA_SETTINGS_TOKEN. Gitea RESERVES the `GITEA_` prefix for secret names -- exactly as GitHub reserves `GITHUB_` -- and rejects that PUT with: HTTP 400 {"message":"invalid secret name"} The script sent the PUT to /dev/null and printed "==> stored." unconditionally, and `curl -sS` exits 0 on an HTTP error, so it reported success for a store that never happened. Measured afterwards: the token existed in the user's token list, and the repo's secret list was EMPTY. ci/gitea-settings.sh would have skipped on every CI run forever, and with REQUIRE_GITEA_SETTINGS=true it would instead have BLOCKED EVERY PR -- including the one fixing it. Three changes: * the secret is SETTINGS_API_TOKEN; ci/gitea-settings.sh reads it, keeping GITEA_SETTINGS_TOKEN as a local-run fallback; * set-ci-token.sh checks the PUT's HTTP status AND reads the secret back, refusing to claim success otherwise. That missing verification is the actual defect -- the wrong name was just what it hid; * gate.yml maps the secret and ENABLES REQUIRE_GITEA_SETTINGS. WHY ENABLING IT HERE IS SAFE: this PR's own CI run is the proof. If the stage were still skipping, REQUIRE turns that into a failure and this PR goes RED rather than merging. Green means the token resolved and live Gitea matched infra/gitea/expected-branch-protection.json. Verified locally before pushing: REQUIRE=true, token present -> MERGE GATE: PASS REQUIRE=true, no token -> gitea-settings SKIPPED -> BLOCKED (not a silent skip) The secret is already stored and read back as present, so CI has what it needs. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 12:08:12 -05:00
jakman85andClaude Opus 5	e6f6e4febb	feat(ci): detect Gitea settings drift -- the blind spot that hid a month of outage ... Every check in this repo reads the repository, the rendered manifests, or the cluster. NONE could see Gitea's own database, and that is where branch protection and runner registration live. Three failures came out of that blind spot on 2026-09-29, all the same shape -- a setting that READ as enforced while not being, with nothing able to notice: * main had NO branch protection for ~a month while DECISIONS-LOG recorded it as a required status check; * ZERO Actions runners were registered, so PR #1 -- the first PR this repo ever had -- sat pending for 30.6 minutes with nothing to execute it; * after enable_status_check and required_approvals were turned on they STILL did not bite, because block_admin_merge_override was false: PRs #5-#9 merged with zero approvals recorded against required_approvals: 1. infra/gitea/*.sh ASSERT the desired state. Nothing DETECTED drift from it. This is the detector. ci/gitea-settings.sh runs as a merge-gate stage: it diffs the live rule at /branch_protections/main against infra/gitea/expected-branch-protection.json and asserts at least one runner is online. It reads the RULE object, not /branches/main -- the branch view does not expose block_admin_merge_override and showed all-green while the rule was overridable by the only account that merges. Verified by test, not assumed: no token -> exit 3, skips loudly, does NOT block live == declaration -> exit 0 injected drift -> exit 1, blocks, naming both the drifted key and the runner count The skip is DELIBERATELY not in gate.sh's strict-skips loop. Making an absent credential block every PR is precisely the lock-yourself-out failure this repo keeps walking into, so a skip denies a PASS (exit 3) and says loudly what is unverified. REQUIRE_GITEA_SETTINGS=true upgrades it to a block once the token is wired. gate.yml's `|| [ "$?" -eq 3 ]` tolerance now covers a second stage. That widening is declared in the file rather than left to be discovered, and it narrows back the moment REQUIRE_GITEA_SETTINGS is set. infra/gitea/set-ci-token.sh mints the token and stores it as the repo Actions secret without ever printing the value. UNTIL THAT TOKEN EXISTS THIS STAGE SKIPS, AND A SKIPPED DETECTOR DETECTS NOTHING. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>	2026-09-29 02:52:28 -05:00