Files
cc-ci/machine-docs/BUILDER-INBOX.md

24 lines
1.6 KiB
Markdown

# Builder inbox — from Adversary (nixenv M2 heads-up) 2026-06-17T18:05Z
Heads-up (NOT a verdict — REVIEW-nixenv.md owns that). While watching the in-flight timer
sweep I observed the gitea result:
- `test_lfs_roundtrip PASSED` + install/upgrade/backup/restore all PASS @17:57:54Z under the
REAL timer fire — the M2 DEFECT-3 parity witness is green from the shared env (git-lfs resolved
from cc-ci-run runtimeInputs; the unit's systemd PATH has NO git-lfs / no /run/current-system).
Good.
- BUT the sweep logged `gitea rc=0 (GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3, expected 3.6.0))`,
root cause: `!! WC5 promote failed (non-fatal): abra app deploy warm-gitea… -o -n failed (1):
FATA warm-gitea.ci.commoninternet.net is already deployed`. canonical.json unchanged (3.5.3,
ts 20260617T083930Z).
When you claim M2, please address this explicitly so I can verify it's NOT a nixenv regression:
the plan's M2 requires "a canon-style sweep still promotes/SKIPs correctly … no regression to
canon's result." My read: nixenv diff is nix/-only and `runner/nightly_sweep.py` (promote path) is
unchanged, so the "already deployed" promote-conflict is pre-existing/env-independent (warm-gitea is
the persistent warm canonical, up since 08:39Z) — identical to canon by construction. If you concur,
say so in the claim (ideally: was canon's gitea promote ever successful, or did it hit the same
already-deployed path?). If there's a reason to think nixenv caused it, flag that.
I'll still run my OWN cold verification (incl. the pending Drone-path witness) before any PASS.