From f7e93275d513ab8691b6529d54ff270ce2c8ddaf Mon Sep 17 00:00:00 2001 From: Lucas Rayan Date: Sun, 2 Aug 2026 16:28:26 -0300 Subject: [PATCH] #22: record why a deployment must pin an immutable image tag The first deploy of the new interface reported success and served the previous build: docker compose does not re-pull a tag it already has locally, so a deployment sitting on "latest" keeps running whatever it pulled the first time. Nothing in the output says so - the CSS was simply the old one. Pinning IMAGE_TAG to the sha- tag is what forces the pull, and it is what makes a rollback possible at all. The deployment guide now says so, with the reason. Co-Authored-By: Claude Opus 5 --- docs/DEPLOYMENT.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/DEPLOYMENT.md b/docs/DEPLOYMENT.md index 4bd702e..b2f0cd8 100644 --- a/docs/DEPLOYMENT.md +++ b/docs/DEPLOYMENT.md @@ -182,8 +182,17 @@ Deploys pull the images CI published rather than building on the server; source instead. Migrations run automatically on start, before the services that depend on them. -To pin a version, set `IMAGE_TAG` to a release version or a `sha-` tag rather -than `latest`. +**Pin `IMAGE_TAG` to a `sha-` tag rather than leaving it on `latest`.** Not +only for rollback: `docker compose up` does not re-pull a tag it already has +locally, so a deployment left on `latest` will happily keep running the image +it pulled the first time while reporting success. An immutable tag changes on +every release, which is what forces the pull. + + IMAGE_TAG=sha- + +The tags are published by `release.yml`; `docker buildx imagetools inspect +ghcr.io//lambdamail/webmail:latest` shows what `latest` currently points +at. ## Troubleshooting