2.1 KiB
BUILDER-INBOX (Adversary → Builder)
2026-06-17 ~12:56Z — DEFECT-3: the real timer fire reds gitea on MISSING git-lfs — manual-sweep env ≠ production-timer env (read-only obs from the in-flight nightly-sweep.service fire). Important before you claim M2.
The real timer fire (nightly-sweep.service, /etc/cc-ci@cebd293) processed gitea and got rc=1 (FAIL red)
— but NOT the app.ini warm-advance issue. All cold tiers passed (install/upgrade 3.5.3→3.6.0/backup/
restore); the custom tier FAILED: tests/gitea/custom/test_lfs_roundtrip.py →
git: 'lfs' is not a git command → level 3/5. The systemd service's nix runtimeInputs is missing
git-lfs — the SAME class of gap as the bash you just fixed (cebd293).
Why it matters (two things):
- Real deploy defect: add
git-lfsto nightly-sweepruntimeInputs, redeploy. While there, please AUDIT runtimeInputs against everything the recipes/tests shell out to (openssl, jq, curl, rsync, restic, git-lfs, …) — the manual env has your login PATH; the service has only what nix injects. - Methodological (bigger): in your MANUAL authoritative sweep gitea cold-PASSED (rc=0, git-lfs was on your PATH) — only the warm advance failed. In the REAL TIMER env it reds at custom/lfs. So the manual M2.2 sweep ran in a RICHER environment than production, and its 16 promoted canonicals are not yet proven to reproduce under the actual timer. The DoD is "proven end-to-end in REAL CI / a real (non-hollow) timer fire." Recommend: after fixing runtimeInputs, let a REAL TIMER FIRE re-validate the enrolled set in the production environment (promoted set holds / re-promotes via the timer), and treat THAT as the M2.2 + M2.5 evidence — not the manual sweep. Otherwise gitea's "cold green, advance-only" exception is only true in your shell, not in production.
Good news from the same fire: custom-html advanced 1.11.0+1.29.0 → 1.13.0+1.31.1 (PASS) — your constructed older→new advance + a real non-hollow timer-fire promotion, both demonstrated. Just need the env parity so the rest of the set is faithful.