845b86c868
Per Adversary course-correction (bdef282) + plan-ccci-compose-overlay-policy.md §1: upgrade-to-latest
is MANDATORY. The 0.7.0+3.3.1 from-version pins the Docker-Hub-removed bitnami/discourse:3.3.1 (404)
and ships a too-tight 5m start_period for the 15-25min Rails cold boot. Minimal base overlay
compose.ccci.yml re-pins app+sidekiq to bitnamilegacy/discourse:3.3.1 (namespace-only, identical
image — same re-pin the PR head makes) + widens start_period to 20m (grace-only). install_steps.sh
provides it; CHAOS_BASE_DEPLOY skips the clean-tree gate; UPGRADE_BASE_VERSION=0.7.0+3.3.1 sets the
true predecessor. Neither change weakens a test. Run shape returns to STAGES=install,upgrade,backup,
restore,custom.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
39 lines
2.8 KiB
Python
39 lines
2.8 KiB
Python
# Per-recipe harness config for discourse (Phase 2 Q4.6 — forum; postgres + redis + sidekiq).
|
|
#
|
|
# Discourse (bitnamilegacy/discourse) is a slow-booting Rails app: the recipe healthcheck polls
|
|
# /srv/status, and a cold first boot (DB migrate + asset precompile) regularly takes 15-25 min on
|
|
# cc-ci's single node, 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 # slow Rails cold boot (15-25min); matches the EXTRA_ENV TIMEOUT below
|
|
HTTP_TIMEOUT = 1200
|
|
|
|
# Slow-cold-boot handling: the recipe-PR (recipe-maintainers/discourse#1) bumps the app healthcheck
|
|
# `start_period` to a LITERAL 20m for the HEAD. discourse's 15-25min Rails cold boot (DB migrate +
|
|
# asset precompile) exceeds the published 5m start_period → swarm would kill the still-booting app.
|
|
# start_period CANNOT be an env var (abra validates the literal compose 'duration' BEFORE substitution
|
|
# → `FATA ...Does not match format 'duration'`; Adversary-reproduced, REVIEW-2 4b862f6), so a literal
|
|
# recipe-PR bump is the only §9-compliant way to widen it. start_period is grace-only (a healthy check
|
|
# still marks healthy immediately → fast hosts unaffected). Precedent: lasuite-drive collabora PR.
|
|
# TIMEOUT (abra's internal convergence wait) is raised to outlast the boot.
|
|
#
|
|
# UPGRADE-tier BASE (compose.ccci.yml + UPGRADE_BASE_VERSION): upgrade-to-latest must ALWAYS run
|
|
# (plan-ccci-compose-overlay-policy.md §1). The from-version is the latest published 0.7.0+3.3.1
|
|
# (UPGRADE_BASE_VERSION below; the PR head is 0.7.0-based, so 0.7.0 is the true predecessor — not the
|
|
# default [-2]=0.6.3). The published 0.7.0 has TWO blockers, both resolved by the policy-blessed
|
|
# minimal base overlay compose.ccci.yml (see its header), neither weakening a test:
|
|
# (1) it pins the Docker-Hub-removed `bitnami/discourse:3.3.1` (404) → overlay re-pins app+sidekiq to
|
|
# `bitnamilegacy/discourse:3.3.1` (namespace-only, identical image), the same re-pin the PR makes;
|
|
# (2) its 5m start_period is too tight for the 15-25min Rails boot → overlay widens it to 20m (grace).
|
|
# install_steps.sh provides the overlay; CHAOS_BASE_DEPLOY skips the clean-tree gate on the untracked
|
|
# overlay; it persists across the head checkout (idempotent — the PR head already re-pins + ships 20m).
|
|
# Upgrade crossover: 0.7.0 (re-pinned base) → PR head; full assertions run on the HEAD. The 0.7.0
|
|
# *custom* tests are not separately run (custom tier runs once, on the head — policy §1 allows skip+record).
|
|
CHAOS_BASE_DEPLOY = True
|
|
UPGRADE_BASE_VERSION = "0.7.0+3.3.1"
|
|
EXTRA_ENV = {
|
|
"TIMEOUT": "2400",
|
|
"COMPOSE_FILE": "compose.yml:compose.ccci.yml",
|
|
}
|