From 880ba78446d5c925ebb90174500451150cdf27b8 Mon Sep 17 00:00:00 2001 From: autonomic-bot Date: Sat, 30 May 2026 13:38:16 +0100 Subject: [PATCH] =?UTF-8?q?status(2):=20discourse=20upgrade-tier=20blocked?= =?UTF-8?q?=20=E2=80=94=20ALL=20prev=20published=20versions=20pin=20remove?= =?UTF-8?q?d=20bitnami=20images=20(3.1.2+3.3.1=20gone);=20plan=20maximal?= =?UTF-8?q?=20subset=20install,backup,restore,custom=20+=20=C2=A77.1=20sig?= =?UTF-8?q?n-off=20for=20upgrade=20tier?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- machine-docs/STATUS-2.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/machine-docs/STATUS-2.md b/machine-docs/STATUS-2.md index 4b1840f..f65e507 100644 --- a/machine-docs/STATUS-2.md +++ b/machine-docs/STATUS-2.md @@ -1088,3 +1088,18 @@ Drone re-tests the *trigger*, not the *recipe tests* (which is what Phase 2 is a OPERATOR decision, so this is flagged for operator input (not self-grantable). Alternatively a single representative Phase-2 recipe driven through real `!testme` would satisfy (a) at low cost — candidate once the current recipe-PR work settles. **OPEN — operator pick (a) vs (b) before DONE.** + +### discourse Q4.6 — UPGRADE TIER blocked by upstream image removal of PREV versions @2026-05-30 +FULL run (`/root/ccci-discourse-full.log`, STAGES=install,upgrade,backup,restore,custom) install tier +FAILED at 2400s. CAUSE: with `upgrade` in STAGES, the install base-deploys the PREVIOUS published +version (0.6.3+3.1.2) so upgrade can go prev→head — but that prev version's compose pins +`bitnami/discourse:3.1.2`, which Docker Hub ALSO removed (same emptying as 3.3.1). Every published +discourse tag (0.6.3+3.1.2, 0.7.0+3.3.1) references a now-removed bitnami image, so NO prev version is +deployable → the HC1 upgrade-crossover tier cannot run. (install+custom passed in pr5 because that mode +base-deploys the PR HEAD directly = re-pinned bitnamilegacy/discourse:3.3.1.) Re-pinning a published +*tag* would mean rewriting published mirror history — not appropriate. +**PLAN (maximal subset, §7.1 pattern like drone/plausible):** run `STAGES=install,backup,restore,custom` +on PR head → gives P1 (install serving) + P4 (backup/restore data-integrity) + P3 (create-topic/site) + +P2 N/A. Document the **upgrade tier** as a genuine upstream-image-removal constraint (all prev published +images gone) and request Adversary §7.1 sign-off for that one tier. NOT a weakened test — the upgrade +machinery is fine; there is simply no servable prev image to upgrade FROM.