Docker Compose fragments (anchors/aliases) bug

[guicbrito]

Description

Docker Desktop v4.35.0 recently updated docker compose to v2.29.7, which has a bug with fragments (yaml anchors and aliases). In short, after the upgrade, running docker compose projects that have anchors or aliases in service definition with a name starting with the same name as a previously defined one causes a regression.

$>docker compose --profile dev up
cycle detected at path: services.web-test.1

The bug was reported here: docker/compose#12247
It seems there is a fix pushed on Docker Compose v2.30.1. (compose-spec/compose-go#704).

Could Docker Desktop release a hotfix bumping Docker Compose to v2.30.1? I'm unable to run any of my projects using fragments since the update yesterday.
I'm running Docker Desktop for Windows using the WSL2 backend.

Reproduce

$>docker compose --profile dev up
cycle detected at path: services.web-test.1

See docker/compose#12247

Expected behavior

docker compose up was running fine before v4.35.0 update.

docker version

Client:
Version: 27.0.3-1
API version: 1.46
Go version: go1.21.12
Git commit: 7d4bcd863a4c863e650eed02a550dfeb98560b83
Built: Fri Jun 28 14:56:30 UTC 2024
OS/Arch: linux/amd64
Context: default

Server: Docker Desktop ()
Engine:
Version: 27.3.1
API version: 1.47 (minimum version 1.24)
Go version: go1.22.7
Git commit: 41ca978
Built: Fri Sep 20 11:41:11 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.21
GitCommit: 472731909fa34bd7bc9c087e4c27943f9835f111
runc:
Version: 1.1.13
GitCommit: v1.1.13-0-g58aa920
docker-init:
Version: 0.19.0
GitCommit: de40ad0

docker info

Client:
Version: 27.0.3-1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: 0.17.1-1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.30.0
Path: /usr/libexec/docker/cli-plugins/docker-compose

Server:
Containers: 8
Running: 1
Paused: 0
Stopped: 7
Images: 11
Server Version: 27.3.1
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: nvidia runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 472731909fa34bd7bc9c087e4c27943f9835f111
runc version: v1.1.13-0-g58aa920
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.153.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 19.54GiB
Name: docker-desktop
ID: 7c7c987e-256f-4754-9327-3a1cbea2a386
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Labels:
com.docker.desktop.address=unix:///var/run/docker-cli.sock
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile

Diagnostics ID

491ACFF0-5DE7-481C-876C-4759358357DD/20241030132153

Additional Info

No response

[guicbrito]

It seems Docker Compose v2.29.7 doesn't have the bug, which was happening due to me running v2.30.0 inside a container with docker-outside-of-docker.
I'm closing this issue, as the bug is with docker-outside-of-docker using v2.30.0, not Docker Desktop for Windows, which has v2.29.7.