fix(deploy): force-recreate caddy on its roll so config-only changes apply
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 15s
CI / ui (pull_request) Successful in 54s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m20s
CI / changes (pull_request) Successful in 2s
CI / unit (pull_request) Successful in 10s
CI / integration (pull_request) Successful in 15s
CI / ui (pull_request) Successful in 54s
CI / gate (pull_request) Successful in 0s
CI / deploy (pull_request) Successful in 1m20s
The prod rolling deploy rolls each service with `compose up -d --no-deps <svc>`. For caddy that is a no-op on a config-only release: its image is pinned (caddy:2-alpine, no $TAG), so the compose definition is unchanged between releases, compose treats the container as current and does not recreate it, and admin is off so there is no hot reload. The new bind-mounted Caddyfile is seeded to the host but never loaded -- the v1.2.2 `Alt-Svc: clear` edge fix deployed green yet did not take effect until caddy was restarted by hand. Force a recreate for caddy on its roll (every other service already recreates on its new $TAG image), so a bind-mounted Caddyfile change always applies. Costs a ~1-2s caddy blip per deploy, acceptable for the infrequent manual prod rollout.
This commit is contained in:
+3
-1
@@ -150,7 +150,9 @@ Re-run `ansible/` after a host resize — it is idempotent.
|
||||
workflow manually (Gitea → Actions → prod-deploy → run from `master`, input
|
||||
`confirm=deploy`). It builds + pushes the images to the registry, ships the
|
||||
compose/config/certs/env over SSH, deploys the main host with `prod-deploy.sh` (rolling,
|
||||
health-gated, **auto-rollback to the previous tag**), then the bot host, then probes the
|
||||
health-gated, **auto-rollback to the previous tag**; caddy is force-recreated on its roll so
|
||||
a bind-mounted `Caddyfile` change applies — its image is pinned and admin is off, so neither a
|
||||
new tag nor a hot reload would pick it up), then the bot host, then probes the
|
||||
public site. After `master` is green this workflow is the **only** thing that touches
|
||||
prod — nothing auto-deploys there. It runs four visible jobs: **build → deploy-main →
|
||||
deploy-bot → verify** (the per-service rolling shows in the deploy-main log).
|
||||
|
||||
@@ -74,7 +74,13 @@ health_running() { # health_running <container>: running, not restarting, stable
|
||||
roll() { # roll <service> <health-cmd...>
|
||||
local svc="$1"; shift
|
||||
echo ">>> rolling $svc -> $TAG"
|
||||
dc up -d --no-build --no-deps "$svc" || return 1
|
||||
# caddy's image is pinned (caddy:2-alpine, no $TAG) and its Caddyfile is bind-mounted, so a
|
||||
# config-only change leaves the compose definition unchanged: `up -d` treats the container as
|
||||
# current and does not recreate it, and admin is off so there is no hot reload — the new
|
||||
# Caddyfile would never load. Force a recreate for caddy so config changes always apply; every
|
||||
# other service already recreates on its new $TAG image.
|
||||
local recreate=(); [ "$svc" = caddy ] && recreate=(--force-recreate)
|
||||
dc up -d --no-build --no-deps "${recreate[@]}" "$svc" || return 1
|
||||
"$@" || { echo "!!! $svc failed health check"; return 1; }
|
||||
echo "<<< $svc healthy"
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user