542ed0afe3
Persistent agent memories now live in memory/ in this repo; the Claude auto-memory path is symlinked here so future memories land in the repo and get committed like any other change.
1.7 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| plausible-upgrade-base-trap | 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 |
|
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: the fix is one line in the cc-ci repo (gated by --with-tests / operator):
tests/plausible/recipe_meta.py: UPGRADE_BASE_VERSION = "3.0.1+v2.0.0". The recipe-side
hardening (verified cached binary on the persistent volume, Altinity URL, retries+timeout,
loud hard-fail, depends_on fix) is on PR #3 (commit 9f8bcbc). Diagnosis + ask posted at
recipe-maintainers/plausible#3 (comment).
Before burning a !testme on an upgrade-stage recipe, check what base version the harness
will pick and whether that base can actually converge. See abra-chaos-deploy-checkout-gotcha.