deploy.sh reports the digest and version from before the container was replaced #236

New Issue

Open

opened 2026-09-10 05:18:38 -05:00 by null · 0 comments

null commented

2026-09-10 05:18:38 -05:00

Owner

Seen during the v0.9.6 deploy on 2026-09-10.

What is true now. scripts/deploy.sh finished with:

deploy: checking the live site...
deploy:   ok    https://queuenorth.com
digest   ...aa51d95c  ->  ...aa51d95c
version  0.9.5  ->  0.9.5

The deploy had in fact worked. Seconds later the container was Up (healthy) on v0.9.6, and both pages served the new copy. The script inspected the container before Portainer had finished recreating it, so it compared the OLD container with itself and printed a no-op.

What it costs. The one line an operator reads to confirm a deploy says nothing happened. That is the same shape as the failure the version label exists to prevent: during an incident this is the output that gets trusted. It also means a deploy that genuinely did nothing looks exactly like one that worked.

What to do. Re-read the digest and version label AFTER the health wait, and compare against the tag that was deployed rather than against the value read at the start. If they still disagree, say so and fail: a 200 from the front door is not proof that the new image is running.

Verify: a deploy of an already-running version prints unchanged digest and version and says so, and a deploy that moves the version prints the new digest and version, both read after the container reports healthy.

Seen during the v0.9.6 deploy on 2026-09-10. **What is true now.** `scripts/deploy.sh` finished with: ``` deploy: checking the live site... deploy: ok https://queuenorth.com digest ...aa51d95c -> ...aa51d95c version 0.9.5 -> 0.9.5 ``` The deploy had in fact worked. Seconds later the container was `Up (healthy)` on `v0.9.6`, and both pages served the new copy. The script inspected the container before Portainer had finished recreating it, so it compared the OLD container with itself and printed a no-op. **What it costs.** The one line an operator reads to confirm a deploy says nothing happened. That is the same shape as the failure the version label exists to prevent: during an incident this is the output that gets trusted. It also means a deploy that genuinely did nothing looks exactly like one that worked. **What to do.** Re-read the digest and version label AFTER the health wait, and compare against the tag that was deployed rather than against the value read at the start. If they still disagree, say so and fail: a 200 from the front door is not proof that the new image is running. Verify: a deploy of an already-running version prints unchanged digest and version and says so, and a deploy that moves the version prints the new digest and version, both read after the container reports healthy.