# 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.)