[BUG] 2.31.0 broke referencing local image IDs

[gzm0]

Description

Using an image ID (SHA 256) as image worked until compose 2.29.7.

services:
  test:
    image: f691df868290275974103c307537784a0e457ecfd8f188e06e52b8de8d1439f8

On 2.27.9:

$ docker compose up -d
[+] Running 2/2
 ✔ Network hex-string-test_default   Created                                                                                                                     0.1s 
 ✔ Container hex-string-test-test-1  Started    

On 2.31.0 (and later):

$ docker compose up -d
invalid repository name (f691df868290275974103c307537784a0e457ecfd8f188e06e52b8de8d1439f8), cannot specify 64-byte hexadecimal strings

I suspect

• Fix compose images that return a different image with the same ID #12278

as the culprit, or more specifically, the now unconditional call to reference.ParseDockerRef:

compose/pkg/compose/images.go

Line 97 in a8469db

ref, err := reference.ParseDockerRef(repoTag)

Related:

• Can no longer reference local image with docker-compose #923

Steps To Reproduce

1. Run docker image ls --digests, pick the full digest of any image (without the sha256: prefix).
2. Create a docker-compose.yml like above (but with the digest you picked in the previous step).
3. Run docker compose up

Outcome:

$ docker compose up -d
invalid repository name (f691df868290275974103c307537784a0e457ecfd8f188e06e52b8de8d1439f8), cannot specify 64-byte hexadecimal strings

Expected outcome: Compose starts a container with the image having this ID.

Compose Version

Docker Compose version v2.32.1

Docker Environment

Client: Docker Engine - Community
 Version:    27.4.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.19.3
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.32.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 11
  Running: 1
  Paused: 0
  Stopped: 10
 Images: 118
 Server Version: 27.4.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 88bf19b2105c8b17560993bee28a01ddc2f97182
 runc version: v1.2.2-0-g7cb3632
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-49-generic
 Operating System: Ubuntu 24.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 14
 Total Memory: 30.86GiB
 Name: tos
 ID: 76ad4af6-cdd1-4e15-8191-afde7df486eb
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Registry Mirrors:
  https://dockerhub.mirror.datarepo.ch/
 Live Restore Enabled: false

Anything else?

Workaround:

Add the sha256: prefix. For example: image: sha256:f691df868290275974103c307537784a0e457ecfd8f188e06e52b8de8d1439f8

Note, it seems this causes docker compose images to wrongly "parse" the info:

$ docker compose images
CONTAINER                REPOSITORY          TAG                                                                IMAGE ID            SIZE
hex-string-test-test-1   sha256              f691df868290275974103c307537784a0e457ecfd8f188e06e52b8de8d1439f8   f691df868290        1.69GB

Compare with compose 2.29.7 (both with and without the sha256: prefix when doing compose up):

$ docker compose images
CONTAINER                REPOSITORY          TAG                 IMAGE ID            SIZE
hex-string-test-test-1   <none>              <none>              f691df868290        1.69GB

[gzm0]

I have locally tested that reverting 799ab84 on main (a351585) fixes the issue (including the wrong result of docker compose images).

[gzm0]

/cc @koooge

[gzm0]

I have opened a revert PR (#12444) in case the maintainers judge this needs to be fixed quickly. I will take a stab at adjusting getImageSummaries to handle this case gracefully without re-introducing prior issues.

[koooge]

This is a nice catch. I would get the original issue if reverted. Also it should have a testcase I think.

[gzm0]

FWIW: I can confirm that this is fixed in compose 2.32.3. TY for the quick fix!!