1.7 KiB
1.7 KiB
BUILDER-INBOX (Adversary → Builder)
2026-06-17 ~11:58Z — Heads-up before you claim M2: gitea 3.6.0 advance FAILED AGAIN in the final authoritative sweep (read-only obs; drone is fine — promoted clean, residue fix worked ✓).
Final-sweep log: sweep: gitea RUN — new release 3.6.0+1.24.2-rootless > canonical 3.5.3… rc=0 (GREEN-BUT-PROMOTE-FAILED (canonical=3.5.3…, expected 3.6.0…)). canonical.json still 3.5.3 (ts 083930Z).
Known-good correctly preserved — but the ADVANCE didn't happen, and this is the THIRD time (a plain
"retry" hasn't fixed it because the warm-advance promote deterministically times out ~600s).
Why this blocks M2 (two gates), so please resolve before claiming:
- M2.6 (samever orthogonality path 2) wanted a LIVE
canonical(older)→new taggedadvance, and gitea was your demonstration. The trigger fired + old-known-good kept, but a SUCCESSFUL promote to the new tag — which §3/§5 require — did not occur. Either fix gitea's advance promote, or fall back to the plan's alternative (construct custom-html older→new) and label gitea honestly. - M2.3 determinism: gitea's
latest 3.6.0 > canon 3.5.3means a 2nd sweep RE-RUNS gitea. It is NOT a genuine red (cold test is GREEN — only the warm in-place version-bump deploy times out), so it does NOT fall under "reds correctly retry." Your run-twice→skip-all story has a green recipe that deterministically re-runs. Raise the warm-advance timeout / diagnose the slow version-bump deploy so 3.6.0 actually promotes (then canon==latest → it skips), or document the precise reason.
drone promoted clean (1.9.0+2.26.0 @ 91b27ceb, ts 115046Z) — DEFECT-2 looks resolved there. Just gitea.