Repository navigation
🐛 Fixed an update leaving Caddy on its old configuration - #447
Merged
Merged
Conversation
Compose recreates a container only when its service definition changes. A release that changed only a file Caddy mounts, such as caddy/Caddyfile or a snippet, was written, `up --wait` left Caddy running, and the update was recorded as installed while Caddy kept serving the configuration it had. The shared Caddy's self-update (S13) reloads Caddy explicitly for the same reason; a site with its own Caddy has had this gap since before it. runUpdate, which self-update, `update` and the supervisor share, now runs `caddy reload` once the services are healthy, on a production layout. A configuration Caddy refuses fails the update after startup, so recovery stops the services and puts the files back as for any failed start. Stopped, Caddy reads the restored files when it starts again, so the rollback needs no reload of its own. - manager/src/update.ts: reloadCaddy after up, before verification. - manager/test/site.ts: the scripted site answers `caddy reload`. - manager/test/self-update.test.ts: a production site's update reloads Caddy after up; a refused reload rolls the files back. - docs/caddy.md: an update reloads Caddy, loading unreloaded edits.
|
Warning Review limit reached
This review includes 4 billable files and costs up to $1.00.
Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing. Or wait 9 minutes for your next included review. View limit details
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Compose recreates a container only when its service definition changes. A release that changed only a file Caddy mounts (
caddy/Caddyfile, a snippet) was written,up --waitleft Caddy running, and the update was recorded as installed while Caddy kept serving its old configuration. #427's shared-Caddy self-update reloads explicitly for this reason; a site with its own Caddy had the same gap.Change
manager/src/update.ts:runUpdate(shared byself-update,updateand the supervisor) runsdocker compose exec -T caddy caddy reload --config /etc/caddy/Caddyfileafterup --wait, before verification, when the site layout isproduction. If Caddy refuses the config, the update fails after startup, so the existing recovery runs: services are stopped and the files put back, and the operator is told the site needs them. The error wording matches ✨ Added a shared Caddy for several production sites on one server (S13) #427'scaddyUp.recover()never runsupagain. It stops the services (down, orstopunder the supervisor), so Caddy reads the restored files the next time it starts. That means the rollback doesn't need a reload of its own. The test checks that Caddy is stopped and the files are back.docs/caddy.md: says that an update reloads Caddy. Caddyfile edits the operator hasn't reloaded yet get loaded by that reload, so a Ghostupdatecan now fail on an invalid edit.Tests
self-updatereloads Caddy once, afterup, and records the release.test/site.tsanswerscaddy reload(site.reloads).format:check,lint,typecheckand the unit tests (607) pass locally. e2e is left to CI.Not changed
The released-main migration (
legacy.tsapply) also writes Caddy files and runsup. Itscompose.ymlreplaces main's Caddy service definition, so Compose recreates Caddy there. I left it alone.🤖 Generated with Claude Code