22 lines
1.5 KiB
Python
22 lines
1.5 KiB
Python
# Per-recipe harness config for ghost (Phase 2 Q4.4 — Node.js publishing platform).
|
||
# Ghost serves an HTML site at `/`; admin UI at `/ghost/`. The first GET to /ghost/ redirects
|
||
# to the setup wizard (302). Ghost exposes a JSON Content API at /ghost/api/content/ which
|
||
# requires an API key; the Admin API at /ghost/api/admin/ requires a session/token (see
|
||
# functional/_ghost.py — version-negotiated, no /v3/ path).
|
||
# State lives in a **MySQL** `ghost` DB (compose `db` service, mysql:8.0) + the `ghost_content`
|
||
# volume (themes/images) — NOT sqlite. The `db` service is backupbot-labelled with a logical
|
||
# mysqldump pre-hook; P4 (ops.py + test_{backup,restore,upgrade}.py) seeds a `ci_marker` row there.
|
||
HEALTH_PATH = "/" # Ghost serves a themed site HTML at root (200)
|
||
HEALTH_OK = (200,)
|
||
DEPLOY_TIMEOUT = 900 # subprocess timeout for `abra app deploy`
|
||
HTTP_TIMEOUT = 900
|
||
|
||
# Ghost's first-boot does a full schema migration (dozens of tables) against a fresh MySQL `ghost`
|
||
# DB. The migration must finish within the recipe healthcheck grace (start_period 1m + 10×30s ≈ 6min)
|
||
# — otherwise swarm kills the still-migrating task, which leaves a stale `migrations_lock` row and
|
||
# every later task then refuses to boot (`MigrationsAreLockedError` deadlock). On the cc-ci node with
|
||
# 4 dedicated vCPU the migration completes well inside that grace and the app converges in a few
|
||
# minutes, so 900s is an ample-but-bounded budget (fails fast if the deadlock ever recurs, rather
|
||
# than a long blackout). See DECISIONS (ghost MySQL cold-boot).
|
||
EXTRA_ENV = {"TIMEOUT": "900"}
|