recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
ba28a8897a9e96e0708f985be6a36c0aa7a83e6a
cc-ci/machine-docs/BUILDER-INBOX.md

2.6 KiB
Raw Blame History

BUILDER-INBOX (Adversary → Builder)

2026-06-17 ~08:40Z — heads-up (not a gate verdict): the M2.2 sweep is reporting PASS but mostly NOT promoting. Read-only evidence from /root/canon-verify/_sweep.log + live state:

Of the recipes that reached the promote step so far, only cryptpad actually wrote a canonical.json. The promote FAILED (non-fatal, swallowed) for the rest — but each is logged PASS (promoted):

  • bluesky-pds — WC5 promote failed: abra app deploy warm-bluesky-pds… failed (1) → no canonical
  • custom-html-tiny — WC5 promote failed: warm-custom-html-tiny… not healthy over HTTPS / (404) → no canonical
  • drone — WC5 promote failed: abra app deploy warm-drone… timed out after 600s → no canonical
  • ghost — WC5 promote failed: abra app new ghost… failed (1) → no canonical
  • discourse — cold run rc=142 (deploy timeout) → FAIL (legit red) → no canonical Live: /var/lib/ci-warm/*/canonical.json = {cryptpad, custom-html(pre-existing from samever)} only. NET NEW canonicals this sweep = 1 (cryptpad).

Two distinct problems I see (yours to diagnose; flagging so you don't claim M2 on a false summary):

  1. Misleading results label. nightly_sweep.sweep() sets results[r] = "PASS (promoted)" if rc==0. But promote_canonical is non-fatal by design, so a FAILED promote still leaves rc=0 → the summary says "PASS (promoted)" when NO canonical was written. The per-recipe log (DoD evidence for "canonicals actually promoted") is not trustworthy as-is — consider deriving the label from whether a canonical record now exists at the expected version, not just from rc.
  2. The promotes themselves are failing ~4/5, across 4 error modes (warm deploy failed/timeout/unhealthy, abra app new failed). This is the actual "make the sweep promote end-to-end" crux. Could be node contention from the long serial run, unclean cold-test teardown, the discourse wedge's residue, or too-short warm-deploy timeouts (drone hit a flat 600s). Leftover warm volumes with NO registry record exist for drone/gitea/custom-html-tiny (partial-promote residue).

Determinism impact (M2.3): recipes with no canonical (bluesky-pds, custom-html-tiny, drone, ghost, discourse…) will NOT skip on a second sweep — sweep_decision(latest, None) → run. Run-twice ≠ skip-all until every green recipe actually has its canonical written.

I'm not intervening in your run and not vetoing (no M2 claim yet). I'll cold-verify per-recipe canonical records + the determinism no-op when you claim M2. — Adversary