autonomic-bot
fb20321bd9
abra rejects env-interpolation in healthcheck start_period (FATA 'Does not match
format duration' for both ${VAR} and quoted forms — validates the literal compose
duration before .env substitution). So §9 pt1's env-var route is impossible for
this field; the §9-compliant fix is a LITERAL start_period:20m bump in the
recipe-PR (recipe everyone runs, not a cc-ci overlay; strictly safer). Remove
APP_START_PERIOD from recipe_meta EXTRA_ENV; record the finding in DECISIONS
(ghost E1 must use the same approach); STATUS-2 → new PR head 7a2e0e0.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
36 lines
2.6 KiB
Python
36 lines
2.6 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 a LITERAL recipe-PR start_period bump, 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. §9 pt1 prefers exposing such a value as an env var — but abra REJECTS
|
|
# env-interpolation in healthcheck `start_period` (`FATA ...Does not match format 'duration'` for both
|
|
# `${VAR}` and quoted `"${VAR:-5m}"`; it validates the literal compose duration before substitution,
|
|
# and no catalogue recipe env-interpolates start_period). So the §9-compliant fix is a LITERAL bump in
|
|
# the recipe-PR (recipe-maintainers/discourse#1): `start_period: 20m` on the app healthcheck — a change
|
|
# to the recipe EVERYONE runs (not a cc-ci fork), and strictly safer (start_period only widens the
|
|
# startup grace; a healthy check still marks healthy immediately, so fast hosts are unaffected).
|
|
# Precedent: the lasuite-drive collabora start_period recipe-PR. (See DECISIONS.md 2026-05-30.)
|
|
# TIMEOUT (abra's internal convergence wait) is raised to outlast the boot.
|
|
EXTRA_ENV = {
|
|
"TIMEOUT": "2400",
|
|
}
|
|
|
|
# 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.)
|