1ba0d961a3
Some checks failed
continuous-integration/drone/push Build is failing
The harness default base (recipe_versions[-2]) resolves to 3.0.0+v2.0.0 for the open 3.1.0 upgrade PR. That release predates x86_64 support in the clickhouse entrypoint (added 3.0.1): on this amd64 host it downloads clickhouse-backup-linux-x86_64.tar.gz — a deterministic HTTP 404 — and with set -e + a silenced wget the container exits 1 before logging anything, crash-looping until the deploy times out. The base therefore can never converge, regardless of the PR content (the published tag is immutable). This is exactly the case the harness documents for UPGRADE_BASE_VERSION: a PR adding its version ABOVE the newest published tag, where the true predecessor is [-1] (3.0.1+v2.0.0), not [-2]. The upgrade tier then tests the real operator path 3.0.1 -> 3.1.0. Pairs with recipe-maintainers/plausible#3 (its !testme can only go green once this lands).
32 lines
2.0 KiB
Python
32 lines
2.0 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 once ready, so it cannot distinguish "not ready" from "ready"). 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",
|
|
# 64-char stable value for CI — plausible (Phoenix) requires >= 64 chars
|
|
"SECRET_KEY_BASE": "ccciplausibletestkeybase64charsexactlyforCIephemeral4567890123",
|
|
}
|
|
|
|
# The upgrade tier defaults its base to recipe_versions[-2]. For the 3.1.0 upgrade PR the
|
|
# published tags end [..., 3.0.0+v2.0.0, 3.0.1+v2.0.0], so [-2] picks 3.0.0 — whose clickhouse
|
|
# entrypoint has no x86_64 ARCH mapping (added in 3.0.1): on amd64 it wgets the nonexistent
|
|
# clickhouse-backup-linux-x86_64.tar.gz (HTTP 404), exits 1 silently (set -e + silenced wget)
|
|
# and crash-loops, so the base deploy can NEVER converge on this host. The PR adds its version
|
|
# ABOVE the newest published tag — the documented case where the correct base is [-1], the
|
|
# newest published version. Pin it.
|
|
UPGRADE_BASE_VERSION = "3.0.1+v2.0.0"
|