fix: pull the backend image through the shim, not the external Compose binary (#85) - #86
Merged
Merged
Conversation
…e binary The first deploy after the registry move failed at the pull step with an authorisation error, immediately after a login that reported success. On the deployment host `docker` is the podman compatibility shim, but `docker compose` hands off to a separate, real Compose binary. The two do not share a credential store: the login is recorded where podman keeps its credentials, while the external Compose binary looks for a Docker-style config.json and finds none. Any registry requiring authentication therefore fails under `compose pull` even directly after a successful login. Pull with `docker pull` instead, which stays inside the shim and uses the credentials the login actually wrote. Compose then finds the image already present locally and does not need to fetch it. The image reference is read from the compose file so the two cannot drift apart. The failure itself behaved correctly: the pull is checked before any container is stopped, so the running service was untouched and the run reported failure rather than a success that shipped nothing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Ref #85
Follow-up to #84. The first deploy after the registry move failed at the pull step.
What happened
The login succeeded and the pull immediately failed as unauthorised.
Why
On the deployment host
dockeris the podman compatibility shim, butdocker composehands off to a separate, real Compose binary. The two do not share a credential store — the login is recorded where podman keeps its credentials, while the external Compose binary looks for a Docker-styleconfig.jsonand finds none.So any registry that requires authentication fails under
compose pull, even directly after a login that reported success. The previous registry was reached the same way, so this was latent before the move; it only surfaced now because the failure is no longer swallowed.Fix
Pull with
docker pull, which stays inside the shim and uses the credentials the login actually wrote. Compose then finds the image locally and does not need to fetch it itself. The image reference is read out of the compose file rather than duplicated, so the two cannot drift apart.The guard worked
Worth recording: the pull is checked before any container is stopped, so the running service was never touched and stayed healthy throughout. Under the previous behaviour this same failure would have been reported as a successful deploy that shipped nothing.
🤖 Generated with Claude Code