Use content digest for pulled service images

[benjick]

What I did

pullServiceImage returned the pulled image's raw inspect ID, while getImageSummaries resolves already-local images through contentDigest (the platform image-manifest digest, introduced for #13636). Both values feed the com.docker.compose.image label that mustRecreate compares to detect image changes - so the two paths disagreeing made the first up after the pulling up see a phantom image change and recreate every container once, with no change to the project, the image, or the compose file.

Under the containerd image store a tag@digest image reference triggers this reliably: the pull path records the index digest (the raw inspect ID) on the container, and the next up resolves the same image to its platform manifest digest via contentDigest. The strings differ, mustRecreate fires, and the replacement container gets the platform digest - so it happens exactly once per container, which makes it easy to miss but breaks any workflow that relies on up being idempotent (we hit it because our orchestrator asserts unchanged services are never recreated across reconciles).

The fix makes pullServiceImage resolve the pulled image through the same manifests-aware inspect + contentDigest call getImageSummaries uses, so both sides of the staleness comparison speak the same scheme. Engines without manifest support (API < 1.48) keep the previous behavior via contentDigest's plain-ID fallback.

Repro

$ docker run -d --privileged --name repro -e DOCKER_TLS_CERTDIR= docker:dind   # 29.7.0, containerd store
$ cat repro.yml
services:
  app:
    image: alpine:3.19@sha256:6baf43584bcb78f2e5847d1de515f23499913ac9f12bdf834811a3145eb11ca1
    command: ["sleep", "infinity"]
# (compose v5.4.0 as the CLI plugin inside the dind)
$ docker compose -f repro.yml -p repro up -d   # pulls, creates container A
$ docker compose -f repro.yml -p repro up -d   # => "Recreated" - container replaced, nothing changed
$ docker compose -f repro.yml -p repro up -d   # stable from here on

The two containers' com.docker.compose.image labels show the mismatch: container A carries sha256:6baf... (the pinned index digest), its replacement carries the platform manifest digest. v5.3.1 does not exhibit this; it appeared when the local-inspect side moved to contentDigest.

Verification

• New unit test TestPullServiceImageUsesContentDigest fails against the old return value and passes with the fix.
• go build ./..., go vet ./pkg/compose/, gofmt -s -l clean; go test ./pkg/compose/ passes.
• End-to-end against a fresh docker:dind (29.7.0): with this fix the container from the pulling up survives repeated up runs (same container ID); unpatched v5.4.0 recreates it on the second up.

Related: #13636 (the fix that introduced contentDigest for the local-inspect path; this aligns the pull path with it).

---

Disclosure: this PR was prepared by Claude Code (Anthropic) - the diagnosis, fix, tests, and the verification runs above - in an agentic session I directed. I'm the submitter and point of contact.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
pkg/compose/images.go	63.63%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!