f611dda893
All checks were successful
continuous-integration/drone/push Build is passing
plausible's canonical is established at 3.1.0+v2.0.0 (latest), so the dynamic resolver no longer needs the explicit pin: a same-version head steps back to newest-older = 3.0.1+v2.0.0 (NOT the broken 3.0.0). Verifying live before stripping the key globally (§2.G gate). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
39 lines
2.6 KiB
Python
39 lines
2.6 KiB
Python
# Per-recipe harness config for plausible (Phase 2 Q4.7 — analytics platform).
|
|
# Requires SECRET_KEY_BASE (64+ char), DISABLE_AUTH, DISABLE_REGISTRATION env vars to deploy.
|
|
# We use a fixed CI value for SECRET_KEY_BASE — safe for ephemeral per-run deploys.
|
|
HEALTH_PATH = "/api/health"
|
|
HEALTH_OK = (200,)
|
|
# plausible's app starts before its clickhouse events DB is ready (the recipe's `app` depends_on lists
|
|
# `events_db` but the service is named `plausible_events_db`, so swarm applies no ordering) and returns
|
|
# 500 until clickhouse + DB migrations finish — several minutes on a cold deploy. The dedicated
|
|
# /api/health endpoint returns 200 with {"clickhouse":"ok","postgres":"ok","sites_cache":"ok"} only
|
|
# once both datastores are ready, so it is a true readiness probe; `/` is unreliable (500s during init;
|
|
# 302s to /register once ready — and with the pre-2026-06-11 62-char SECRET_KEY_BASE every HTML render
|
|
# 500'd permanently, see EXTRA_ENV). Give a wide HTTP window so the health poll waits out that init.
|
|
# [v1 failed at HTTP_TIMEOUT=600 polling `/`.]
|
|
DEPLOY_TIMEOUT = 1200
|
|
HTTP_TIMEOUT = 1200
|
|
|
|
# Phase-2: configure the recipe's required env (no placeholders allowed).
|
|
EXTRA_ENV = {
|
|
"DISABLE_AUTH": "true",
|
|
"DISABLE_REGISTRATION": "true",
|
|
# Stable CI value, 68 chars — Phoenix's cookie session store requires >= 64 BYTES and raises
|
|
# `ArgumentError ... at least 64 bytes` → HTTP 500 on EVERY page render (HTML routes only;
|
|
# /api/* never touches the cookie store, so health + event tests were unaffected) if it is
|
|
# shorter. The previous value was 62 chars, which is why every page (and the app screenshot)
|
|
# 500'd while the API tiers all passed (phase-shot root cause, 2026-06-11).
|
|
"SECRET_KEY_BASE": "ccciplausibletestkeybase64charsexactlyforCIephemeralrun4567890123456",
|
|
}
|
|
|
|
# canon §2.G: UPGRADE_BASE_VERSION pin REMOVED. It existed because the OLD static `[-2]` default
|
|
# picked the broken 3.0.0 (clickhouse entrypoint 404s on amd64 → base never converges). The dynamic
|
|
# resolver (phase prevb) + this recipe's established canonical make the pin redundant: the canonical
|
|
# is 3.1.0+v2.0.0 (latest), so a sweep run resolves base = last-green canonical, and on a same-version
|
|
# head it STEPS BACK to the newest published version strictly older than 3.1.0 = 3.0.1+v2.0.0 (NOT the
|
|
# broken 3.0.0). Verified live (canon M2.8): the upgrade tier resolves base 3.0.1 and passes green.
|
|
|
|
# canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
|
|
# The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.
|
|
WARM_CANONICAL = True
|