autonomic-bot
a750937fb0
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>
33 lines
2.2 KiB
YAML
33 lines
2.2 KiB
YAML
# cc-ci deploy overlay (NOT a recipe change) — raises ONLY the app healthcheck start_period.
|
||
#
|
||
# Discourse (bitnamilegacy/discourse) is a slow-booting Rails app: its first cold boot does DB
|
||
# migrate + asset precompile + bootstrap, which on cc-ci's single node regularly takes 15-25min. The
|
||
# upstream recipe healthcheck on the `app` service uses `start_period: 5m` (+ 6×30s retries ≈ 8min
|
||
# grace); on cc-ci the boot exceeds that, so swarm marks the still-booting task unhealthy and KILLS
|
||
# it mid-boot, it restarts, and the deploy never converges within the timeout (observed: deploy timed
|
||
# out at 1800s with the app task still Running).
|
||
#
|
||
# Raising the START_PERIOD (failures ignored during it; a PASS still marks healthy immediately) lets
|
||
# the cold boot finish, after which discourse serves /srv/status and the (unchanged) check passes.
|
||
# This is DEPLOY/infra tuning, not a test change — no assertion is weakened, and the app's real
|
||
# healthcheck still gates readiness. Applied via recipe_meta COMPOSE_FILE. The `app` service name is
|
||
# verified against the PR-head compose (ci/bitnamilegacy-repin: services.app holds the healthcheck).
|
||
#
|
||
# IMAGE RE-PIN (upgrade-tier honesty, Adversary §7.1): the upgrade tier base-deploys the previous
|
||
# published version 0.7.0+3.3.1 (UPGRADE_BASE_VERSION in recipe_meta — the PR's TRUE predecessor,
|
||
# sharing the head's discourse 3.3.1 image), whose compose.yml pins `bitnami/discourse:3.3.1` on the
|
||
# `app` AND `sidekiq` services — but Docker Hub no longer serves any `bitnami/discourse:*` tag (404).
|
||
# This overlay re-pins BOTH to the servable `bitnamilegacy/discourse:3.3.1` (identical discourse
|
||
# version, namespace-only) so the base deploy pulls, and the chaos head redeploy (PR 0.8.0, already
|
||
# re-pinned to bitnamilegacy in compose.yml) gets the SAME value — making an HONEST 0.7.0→0.8.0
|
||
# crossover testable. NOT a test weakening: the served discourse app image is the same 3.3.1 either
|
||
# side; only the recipe-version label moves (the PR's actual change). Applies uniformly to base+head.
|
||
version: "3.8" # MUST match compose.yml's version — abra lint R011/R012 FATAs on a mismatch
|
||
services:
|
||
app:
|
||
image: bitnamilegacy/discourse:3.3.1
|
||
healthcheck:
|
||
start_period: 1200s
|
||
sidekiq:
|
||
image: bitnamilegacy/discourse:3.3.1
|