Pin image mount digests in WithImagesResolved

[ssam18]

docker compose config --resolve-image-digests pins service image tags to digests but leaves image mounts untouched, so a volume of type image keeps a floating tag. This extends WithImagesResolved so it also pins the source of image mounts the same way it pins the service image. The per image resolution moved into a small helper that is reused for both cases, with a test covering an image mount alongside a bind mount that stays untouched. Reported in docker/compose#13827.

[ssam18]

This is the compose-go side of the fix for docker/compose#13827. Once it lands and gets released I will follow up with a compose PR that bumps compose-go so the config and publish commands pick it up. Happy to tweak the helper naming or add more cases if you would prefer.

[Copilot]

Pull request overview

Extends image digest resolution in the project model so WithImagesResolved pins not only service.Image but also image-type volume mount sources, matching docker compose config --resolve-image-digests expectations (per docker/compose#13827).

Changes:

• Refactors per-image digest pinning into a small helper (resolveImageDigest) reused across service images and image-mount volumes.
• Updates WithImagesResolved to also resolve service.Volumes[*].Source when volume.Type == VolumeTypeImage.
• Adds a unit test covering an image mount being pinned while a bind mount remains unchanged.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
types/project.go	Reuses a helper to pin digests and now resolves image-mount volume sources in addition to service.Image.
types/project_test.go	Adds coverage for resolving an image mount source while leaving bind mounts untouched.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[glours]

The compose-go change itself looks reasonable to me: WithImagesResolved is the right place to extend digest resolution to image mount sources, and the behavior is consistent with how service images are handled today.

That said, I don’t think this is enough to fix the Docker Compose behavior end-to-end. In docker/compose, --lock-image-digests and the publish digest override paths currently build an override that only keeps services.*.image, so any resolved image mount source would still be dropped there. The --no-interpolate --resolve-image-digests path also builds a pseudo-project containing only service images before calling WithImagesResolved.

So a compose-go bump alone won’t fully address docker/compose#13827, and if the follow-up Compose PR only bumps compose-go, Dependabot would cover that anyway. We’ll need corresponding docker/compose changes/tests for the lock/publish/no-interpolate paths, or the scope of this PR should be narrowed accordingly.

I’d also like to see a bit more compose-go coverage here:

• service without image but with a type: image volume;
• already canonical image mount source, ensuring the resolver is not called;
• invalid/unresolvable image mount source.

The WithImagesResolved comment should also be updated since it no longer resolves only service images.