recipe-maintainers/cc-ci
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(2): ghost F2-14b overlay migration — start_period bump moved to recipe-PR (ghost#1 head ae43ffe, literal 15m on app healthcheck); DELETE cc-ci compose.ccci-health.yml + install_steps.sh + COMPOSE_FILE/CHAOS_BASE_DEPLOY. Anti-drift (plan §9): recipe-as-tested == recipe-as-published. env-var start_period impossible (abra pre-subst duration validation, Adversary-reproduced 4b862f6). Next: run ghost on ae43ffe head.

Browse Source
This commit is contained in:
autonomic-bot
2026-05-30 17:20:20 +01:00
parent 2f5900a5a9
commit 0f2cc2d704
3 changed files with 17 additions and 55 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
tests/ghost/recipe_meta.py
View File

@ -12,17 +12,23 @@ DEPLOY_TIMEOUT = 1200 # subprocess timeout for `abra app deploy`
HTTP_TIMEOUT = 900
# Ghost's fresh-DB first boot runs a full schema migration (dozens of CREATE TABLEs, each a separate
# MySQL round-trip → ~6-9min on cc-ci, round-trip-bound so more vCPU doesn't help). The upstream
# recipe healthcheck (`start_period: 1m` + 10×30s ≈ 6min grace) is too tight: swarm kills the still-
# migrating task, leaving a stale `migrations_lock` → every later task deadlocks
# (`MigrationsAreLockedError`). cc-ci provides a DEPLOY overlay `compose.ccci-health.yml` (raises the
# app healthcheck start_period to 900s; failures ignored during it, a PASS still marks healthy at
# once) via COMPOSE_FILE + install_steps.sh, so the fresh migration finishes + releases the lock.
# This is infra/deploy tuning — NO test/assertion is weakened. CHAOS_BASE_DEPLOY lets the pinned base
# deploy proceed with the untracked overlay present. TIMEOUT 1200s = migration (≤9min) + convergence,
# bounded so a genuine failure still fails (not a long blackout). See DECISIONS (ghost MySQL cold-boot).
CHAOS_BASE_DEPLOY = True
# MySQL round-trip → ~6-9min on cc-ci, round-trip-bound so more vCPU doesn't help). The published
# recipe healthcheck used `start_period: 1m` (+10×30s ≈ 6min grace) — too tight on cc-ci: swarm kills
# the still-migrating task, leaving a stale `migrations_lock` → every later task deadlocks
# (`MigrationsAreLockedError`).
#
# FIXED IN THE RECIPE-PR (recipe-maintainers/ghost#1, branch ci/mysql-backup): the app-service
# healthcheck `start_period` is bumped to a literal 15m in the recipe itself — the real recipe
# everyone runs, NOT a cc-ci compose fork. This is the plan §9 / plan-prefer-env-over-compose-overlay.md
# anti-drift path: start_period CANNOT be expressed as an env var (abra validates the literal compose
# 'duration' format BEFORE env substitution — `${VAR}` / `"${VAR:-1m}"` → FATA 'Does not match format
# duration'; reproduced by the Adversary, REVIEW-2 4b862f6), so a literal recipe-PR bump is the only
# §9-compliant way to widen it. Precedent: discourse + lasuite-drive collabora start_period recipe-PRs.
# start_period only widens the startup grace window (a healthy check still marks healthy at once → fast
# hosts unaffected); NO test/assertion is weakened. With the bump in the recipe, the former cc-ci
# DEPLOY overlay (`compose.ccci-health.yml` + `install_steps.sh` + COMPOSE_FILE + CHAOS_BASE_DEPLOY)
# is DELETED. TIMEOUT 1200s = migration (≤9min) + convergence, bounded so a genuine failure still
# fails (not a long blackout). See DECISIONS (ghost MySQL cold-boot / start_period recipe-PR).
EXTRA_ENV = {
"TIMEOUT": "1200",
"COMPOSE_FILE": "compose.yml:compose.ccci-health.yml",
}