fix(build): resolve image volumes to a mountable name, not a manifest digest

[ricardobranco777]

What I did

ImageSummary.ID holds the digest of the platform-specific manifest so ServiceHash stays stable across attested rebuilds (see contentDigest). resolveImageVolumes reused that same value as the type: image mount Source, but the daemon only resolves a mount Source by name/tag or top-level image ID, not by manifest digest — so compose up failed with "No such image" whenever the volume's source image was already present locally (always for a built image; on a second run for a pulled one).

Keep Source as the resolved image name, and track the digest separately via a new com.docker.compose.image-volume-digest label so mustRecreate can still detect a rebuilt/updated source image independently of Source.

Related issue

Fixes #14005

(not mandatory) A picture of a cute animal, if possible in relation to what you did

[glours]

Hi @ricardobranco777, thanks a lot for the thorough investigation on #14005 and for this fix — the analysis was spot on.

While reviewing it we realized this regression is one instance of a broader structural problem: compose records image identities for staleness detection through several independent code paths (pull, bake, classic builder, already-local inspect), and they don't all produce the same kind of digest for the same image (index vs per-platform manifest vs config digest). That mismatch class is what caused #13636, #13998 and #14005, and a few more latent cases we found along the way.

We've addressed the whole class in #14011: a single canonical content-digest producer shared by every path, plus a containerd-store e2e job in CI (the blind spot that let this series slip through). Your commit is included there as-is, with your authorship preserved — your use case is covered by the e2e tests of that PR (TestImageVolume* now run against the containerd image store).

If that works for you, we'll close this PR in favor of #14011 , and feel free to review it there, your feedback would be very welcome.
Thanks again for the report, the openQA catch and the fix!

[ricardobranco777]

Hi @ricardobranco777, thanks a lot for the thorough investigation on #14005 and for this fix — the analysis was spot on.

While reviewing it we realized this regression is one instance of a broader structural problem: compose records image identities for staleness detection through several independent code paths (pull, bake, classic builder, already-local inspect), and they don't all produce the same kind of digest for the same image (index vs per-platform manifest vs config digest). That mismatch class is what caused #13636, #13998 and #14005, and a few more latent cases we found along the way.

We've addressed the whole class in #14011: a single canonical content-digest producer shared by every path, plus a containerd-store e2e job in CI (the blind spot that let this series slip through). Your commit is included there as-is, with your authorship preserved — your use case is covered by the e2e tests of that PR (TestImageVolume* now run against the containerd image store).

If that works for you, we'll close this PR in favor of #14011 , and feel free to review it there, your feedback would be very welcome. Thanks again for the report, the openQA catch and the fix!

Sure. Thanks!