Implements the real 0.7.0+3.3.1 -> 0.8.0+3.3.1 upgrade crossover instead of a
§7.1 skip-with-sign-off (Adversary leans DENY on the deferral; agreed):
- recipe_meta UPGRADE_BASE_VERSION=0.7.0+3.3.1 + generic support in
run_recipe_ci (prev = meta override or previous_version). Harness default
[-2]=0.6.3+3.1.2 is a hollow base (img 3.1.2 != head 3.3.1); [-1]=0.7.0+3.3.1
is the PR's true predecessor and shares head's servable 3.3.1 image.
- compose.ccci-health.yml re-pins services.{app,sidekiq}.image to
bitnamilegacy/discourse:3.3.1 so the 0.7.0 base (compose pins 404 bitnami:3.3.1)
is servable; idempotent on the head (PR already bitnamilegacy).
Consumes Adversary BUILDER-INBOX (deleted), leaves ADVERSARY-INBOX ack; STATUS-2
discourse section updated. Full lifecycle run launching next.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
34 lines
2.2 KiB
Python
34 lines
2.2 KiB
Python
# Per-recipe harness config for discourse (Phase 2 Q4.6 — forum; postgres + redis + sidekiq).
|
|
#
|
|
# Discourse (bitnami/discourse) is a slow-booting Rails app: the recipe healthcheck polls
|
|
# /srv/status with a 5-minute start_period, and a cold first boot (DB migrate + asset precompile)
|
|
# regularly takes 8-15 min, so the deploy/HTTP timeouts are generous. /srv/status returns 200 only
|
|
# once the app is actually serving (the canonical "is discourse up" signal — NOT "/", which may
|
|
# redirect to setup).
|
|
HEALTH_PATH = "/srv/status"
|
|
HEALTH_OK = (200,)
|
|
DEPLOY_TIMEOUT = 2400 # was 1800 — slow Rails cold boot (15-25min) overran it; bumped to match TIMEOUT
|
|
HTTP_TIMEOUT = 1200
|
|
|
|
# cc-ci deploy overlay: discourse's 15-25min Rails cold boot exceeds the recipe healthcheck's
|
|
# start_period:5m (+8min grace), so swarm kills the still-booting app and the deploy never converges
|
|
# (observed: 1800s timeout). compose.ccci-health.yml raises the app healthcheck start_period to 1200s
|
|
# (failures ignored during it; a PASS still marks healthy at once) — DEPLOY/infra tuning, NO test
|
|
# weakened. install_steps.sh provides the overlay into the checkout; COMPOSE_FILE wires it; TIMEOUT
|
|
# 2400 lets abra's convergence wait outlast the boot. CHAOS_BASE_DEPLOY lets the pinned base deploy
|
|
# proceed with the untracked overlay present. (Same pattern as tests/ghost/.)
|
|
CHAOS_BASE_DEPLOY = True
|
|
EXTRA_ENV = {
|
|
"TIMEOUT": "2400",
|
|
"COMPOSE_FILE": "compose.yml:compose.ccci-health.yml",
|
|
}
|
|
|
|
# Upgrade-tier base version (Adversary §7.1): the harness default base = recipe_versions[-2], which
|
|
# for discourse is 0.6.3+3.1.2 (discourse 3.1.2). But this PR (recipe-maintainers/discourse#1) ADDS a
|
|
# version (0.8.0+3.3.1) ABOVE the newest published tag, so the PR's TRUE predecessor is [-1] =
|
|
# 0.7.0+3.3.1 — which shares the head's discourse 3.3.1 image, making an HONEST 0.7.0→0.8.0 crossover
|
|
# testable via the uniform bitnamilegacy:3.3.1 image overlay (compose.ccci-health.yml). [-2]=3.1.2
|
|
# differs from head 3.3.1, so a uniform overlay there would be a hollow (fake-version) base. Pinning
|
|
# the base to [-1] is the correct predecessor whenever a PR adds a version above the catalogue head.
|
|
UPGRADE_BASE_VERSION = "0.7.0+3.3.1"
|