developer/scrabble-game
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

fix(deploy): force-recreate caddy on its roll so config-only changes apply #122

Merged
developer merged 1 commits from feature/prod-deploy-force-recreate-caddy into development 2026-06-22 20:09:43 +00:00
Conversation 1 Commits 1 Files Changed 2
+10 -2
developer commented 2026-06-22 20:03:49 +00:00
Owner
Copy Link
Copy Source

What

Force-recreate caddy on its roll in prod-deploy.sh so a config-only (bind-mounted
Caddyfile) change actually loads on a prod deploy.

Why

The 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 off means there is no hot reload. The
new Caddyfile is seeded to the host but never loaded.

This bit us on v1.2.2: the Alt-Svc: clear edge fix deployed green, yet prod kept
serving Alt-Svc: h3 until caddy was restarted by hand. Verified on the prod host (caddy
uptime predated the deploy; the mounted Caddyfile already contained the fix).

Fix

roll() adds --force-recreate for caddy only (every other service already recreates on
its new $TAG image). Cost: a ~1–2 s caddy blip per deploy — acceptable for the
infrequent, manual prod rollout. Doc note added to deploy/README.md.

Verification

bash -n clean; traced roll() — caddy → up -d --no-build --no-deps --force-recreate caddy, other services unchanged. (Prod is already correct after the manual restart; this
prevents the recurrence.)

## What Force-recreate **caddy** on its roll in `prod-deploy.sh` so a config-only (bind-mounted `Caddyfile`) change actually loads on a prod deploy. ## Why The 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 off` means there is no hot reload. The new Caddyfile is seeded to the host but never loaded. This bit us on **v1.2.2**: the `Alt-Svc: clear` edge fix deployed green, yet prod kept serving `Alt-Svc: h3` until caddy was restarted by hand. Verified on the prod host (caddy uptime predated the deploy; the mounted Caddyfile already contained the fix). ## Fix `roll()` adds `--force-recreate` for caddy only (every other service already recreates on its new `$TAG` image). Cost: a ~1–2 s caddy blip per deploy — acceptable for the infrequent, manual prod rollout. Doc note added to `deploy/README.md`. ## Verification `bash -n` clean; traced `roll()` — caddy → `up -d --no-build --no-deps --force-recreate caddy`, other services unchanged. (Prod is already correct after the manual restart; this prevents the recurrence.)
developer added 1 commit 2026-06-22 20:03:49 +00:00
fix(deploy): force-recreate caddy on its roll so config-only changes apply
CI / changes (pull_request) Successful in 2s
Details
CI / unit (pull_request) Successful in 10s
Details
CI / integration (pull_request) Successful in 15s
Details
CI / ui (pull_request) Successful in 54s
Details
CI / gate (pull_request) Successful in 0s
Details
CI / deploy (pull_request) Successful in 1m20s
Details
e0a5753f1a 
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.
owner approved these changes 2026-06-22 20:09:24 +00:00
developer merged commit d6401bb76c into development 2026-06-22 20:09:43 +00:00
developer deleted branch feature/prod-deploy-force-recreate-caddy 2026-06-22 20:09:43 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
owner
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
owner (Ilia) developer
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: developer/scrabble-game#122
Delete Branch "feature/prod-deploy-force-recreate-caddy"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?