[BUG] extends and nondeterministic parsing of docker-compose.yml

[OssianEriksson]

Description

Since a recent update, docker compose now parses compose files making use of the extends feature in a nondeterministic fashion. This is most clearly illustrated by running docker compose config multiple times and seeing different results. However, this behavior does affect other commands such as docker compose build and docker compose up.

Steps To Reproduce

With the following compose file,

services:
  a:
    build: .
    environment:
      VAR: 1
  b:
    extends: a
    build: .
  c:
    extends: b
    build: .

run docker compose config a couple of times. Most of the time, the output is the expected

name: my-project
services:
  a:
    build:
      context: /my-project
      dockerfile: Dockerfile
    environment:
      VAR: "1"
    networks:
      default: null
  b:
    build:
      context: /my-project
      dockerfile: Dockerfile
    environment:
      VAR: "1"
    networks:
      default: null
  c:
    build:
      context: /my-project
      dockerfile: Dockerfile
    environment:
      VAR: "1"
    networks:
      default: null
networks:
  default:
    name: my-project_default

but sometimes the output is different, e.g.

name: my-project
services:
  a:
    build:
      context: /my-project
      dockerfile: Dockerfile
    environment:
      VAR: "1"
    networks:
      default: null
  b:
    build:
      context: /my-project
      dockerfile: Dockerfile
    environment:
      VAR: "1"
    networks:
      default: null
  c:
    build:
      context: /my-project
      dockerfile: Dockerfile
    networks:
      default: null
networks:
  default:
    name: my-project_default

Note the missing environment key in the c service. My guess is that this is due to the extends key of c being resolved before the extends key of b is resolved. In previous versions of docker/compose, the compose file would be consistently parsed according to my expectation every time.

Compose Version

Docker Compose version v2.24.2

Docker Environment

Client: Docker Engine - Community
 Version:    25.0.1
 Context:    default
 Debug Mode: false
 Plugins:
  compose: Docker Compose (Docker Inc.)
    Version:  v2.24.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 9
  Running: 4
  Paused: 0
  Stopped: 5
 Images: 330
 Server Version: 25.0.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: nvidia runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc version: v1.1.11-0-g4bccb38
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.0-92-generic
 Operating System: Linux Mint 21.2
 OSType: linux
 Architecture: x86_64
 CPUs: 32
 Total Memory: 62.61GiB
 Name: my-computer
 ID: 2803ebe5-f243-4267-b2c8-c0c8f44cbeb8
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response

[glours]

Hey @OssianEriksson
It should have been already address by compose-spec/compose-go#547
Can you give a try to the latest release of Compose?
I'll close the issue as already fixed but feel free to ping me if you still have the problem