autonomic-bot
c346b9763b
Migrate discourse off the cc-ci compose overlay per plan §9 / plan-prefer-env-over-compose-overlay.md:
- recipe_meta: drop UPGRADE_BASE_VERSION + COMPOSE_FILE + CHAOS_BASE_DEPLOY; set APP_START_PERIOD=1200s
via EXTRA_ENV (the recipe-PR exposes start_period: ${APP_START_PERIOD:-5m}); declare upgrade tier N/A
(both published prev bases pin removed bitnami images; Adversary §7.1 granted, REVIEW-2 efe3790).
- delete tests/discourse/compose.ccci-health.yml + install_steps.sh (existed only to copy the overlay).
- DECISIONS.md + STATUS-2 record the §9 guardrail + discourse shape (upgrade N/A, env start_period,
pg_backup restore-hook recipe-PR = 5th data-loss recipe cc-ci caught).
recipe-PR head now 8b8df17 (start_period env var added). Not a claim — run STAGES=install,backup,restore,custom next.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
32 lines
2.1 KiB
Python
32 lines
2.1 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 via env, NOT a cc-ci compose overlay (plan.md §9 anti-drift guardrail):
|
|
# discourse's 15-25min Rails cold boot exceeds the recipe healthcheck's default start_period (5m) +
|
|
# grace, so swarm would kill the still-booting app and the deploy never converges. Rather than fork
|
|
# the recipe with a compose.*.yml overlay (which drifts from what ships), the recipe-PR
|
|
# (recipe-maintainers/discourse#1) parameterizes the app healthcheck as
|
|
# `start_period: ${APP_START_PERIOD:-5m}` (default unchanged for real users); cc-ci just sets a larger
|
|
# value here. TIMEOUT (abra's internal convergence wait) is raised to outlast the boot.
|
|
EXTRA_ENV = {
|
|
"TIMEOUT": "2400",
|
|
"APP_START_PERIOD": "1200s",
|
|
}
|
|
|
|
# Upgrade tier — N/A (declared NOT-TESTABLE under cc-ci; Adversary §7.1 sign-off GRANTED, REVIEW-2
|
|
# efe3790). Both published predecessor versions pin Docker-Hub-removed images:
|
|
# 0.7.0+3.3.1 → bitnami/discourse:3.3.1 (404), 0.6.3+3.1.2 → bitnami/discourse:3.1.2 (404).
|
|
# The recipe-PR re-pins the HEAD to bitnamilegacy/discourse:3.3.1 (a legit upstream fix), but per
|
|
# plan.md §9 / plan-prefer-env-over-compose-overlay.md pt2 we declare an old base whose image is gone
|
|
# NOT-TESTABLE rather than authoring an image-repin compose overlay to resurrect it. So no honest
|
|
# prev→head crossover is deployable here → the upgrade tier is omitted (run STAGES without `upgrade`).
|
|
# (P1 coverage is the maximal subset install+backup+restore+custom; P4 restore-hook is the headline.)
|