Files
cc-ci-orchestrator/memory/plausible-upgrade-base-trap.md
autonomic-bot c33b21fe8d memory: commit session notes (drone P0, weekly-upgrade-queued, mailu/index updates)
Per AGENTS.md 'Agent memory lives in memory/ (in this repo)' — memory notes
must be committed + pushed like any repo change, not left only in the local
~/.claude symlink target.
2026-06-11 20:56:24 +00:00

30 lines
1.8 KiB
Markdown

---
name: plausible-upgrade-base-trap
description: "plausible CI REDs come from the published 3.0.0 base deploy (no x86_64 arch → 404 → silent exit 1), not the PR tree; needs UPGRADE_BASE_VERSION=3.0.1+v2.0.0 in cc-ci tests"
metadata:
node_type: memory
type: project
originSessionId: fc17c9c2-ab6e-4c11-856e-a6a6e160a0ec
---
cc-ci's upgrade tier deploys `recipe_versions[-2]` as the base before upgrading to the PR
head (deploy-once design: the install tier asserts against that base too). For plausible,
tags are `…, 3.0.0+v2.0.0, 3.0.1+v2.0.0` so the default base is **3.0.0+v2.0.0**, whose
entrypoint lacks an x86_64 ARCH mapping → requests `clickhouse-backup-linux-x86_64.tar.gz`
→ HTTP 404 always → `set -e` + silenced wget → container exits 1 with **empty service
logs** → crash-loop → install timeout RED. Nothing in the PR can fix this: the base tag is
immutable history.
**Why:** the PR adds 3.1.0 above the newest published tag — the harness-documented case
where `[-2]` is the wrong base and `[-1]` (3.0.1) is correct.
**How to apply:** RESOLVED 2026-06-09 — `UPGRADE_BASE_VERSION = "3.0.1+v2.0.0"` is merged to
cc-ci main, and PR #3 went GREEN level 4 (build 247). Full debrief:
/srv/cc-ci/.cc-ci-logs/upgrades/plausible-upgrade-2026-06-09.md. Lasting lessons: before
burning a !testme on an upgrade-stage recipe, check what base version the harness picks
(`recipe_versions[-2]`) and whether that base can converge; backup-bot-two 2.4.0 ignores v1
`backupbot.backup.path` labels (use `backupbot.backup.volumes.<vol>.path`, dump INTO a
volume); clickhouse-backup cannot FREEZE TinyLog tables (ecto's schema_migrations — TSV
roundtrip needed); BEAM apps exit 0 on supervision escalation, so swarm `restart_policy`
must be `any`, not `on-failure`. See [[abra-chaos-deploy-checkout-gotcha]].