[BUG] Build context path is wrong since v2.29.0 on edge cases

[tasarren]

Description

Prior to the release of v2.29.0 we could build our images when mixing up YAML configs but now our context path gets messy and fails to build.

This bug only happens whenever you extend from another compose file that already contains a context defined and yours does not, maybe there is a race condition going on here.

This was actually mentioned on the Pull Request from another user compose-spec/compose-spec#376 (comment) but I think the edge case in here is to use the YAML file from which you extend in another folder.

Steps To Reproduce

1. Create a directory for your project /tmp/foo_project
2. Create a YAML Compose for said project /tmp/foo_project/docker-compose.yaml with the following contents

services:
  test:
    build:
      target: otherone
    extends:
      file: "${PROJECT_DIR:?}/custom/docker-compose.custom.yaml"
      service: test-svc

3. Create another YAML in /tmp/foo_project/custom/docker-compose.custom.yaml with the following contents:

services:
  test-svc:
    build:
      context: ${PROJECT_DIR:?}
      target: main

5. Run PROJECT_DIR=/tmp/foo_project docker compose config
   Your output contains both directories, from the base project and the ENV variable we have injected

name: foo_project
services:
  test:
    build:
      context: /tmp/foo_project/custom/tmp/foo_project
      dockerfile: Dockerfile
      target: otherone
    networks:
      default: null
networks:
  default:
    name: foo_project_default

The context path contains both, the custom and the defined context path that contains the real path we should be using which is ${PROJECT_DIR}

Compose Version

2.29.0

Docker Environment

Client:
 Version:    27.0.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  0.15.1
    Path:     /usr/lib/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  2.29.0
    Path:     /usr/lib/docker/cli-plugins/docker-compose

Server:
 Containers: 6
  Running: 5
  Paused: 0
  Stopped: 1
 Images: 7
 Server Version: 27.0.3
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Using metacopy: true
  Native Overlay Diff: false
  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: active
  NodeID: sini0klqdz68nxhifna7ypgzy
  Is Manager: true
  ClusterID: ligh1xx876erg491hy6unruog
  Managers: 1
  Nodes: 1
  Default Address Pool: 10.0.0.0/8  
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 192.168.100.98
  Manager Addresses:
   192.168.100.98:2377
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8fc6bcff51318944179630522a095cc9dbf9f353.m
 runc version: 
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.9.10-zen1-1-zen
 Operating System: Arch Linux
 OSType: linux
 Architecture: x86_64
 CPUs: 12
 Total Memory: 31.17GiB
 Name: msi-laptop
 ID: 5bb71748-2746-410a-8ba6-27389b2990d4
 Docker Root Dir: /opt/docker
 Debug Mode: false
 Experimental: true
 Insecure Registries:
  127.0.0.0/8
 Registry Mirrors:
  https://172.16.31.11:5000/
 Live Restore Enabled: false

EDIT: Typos, sorry, maybe there are more.

Anything else?

No response

[idsulik]

It looks like the same issue as this one #12001

[glours]

👋 @tasarren
I just want to be sure and double check but when you mention version 1.19.1 in fact you mean v2.18.1 right?

[tasarren]

👋 @tasarren I just want to be sure and double check but when you mention version 1.19.1 in fact you mean v2.18.1 right?

Yes, sorry it was late night and it looks like I misread 2.19.1 for 1.19.1... anyways with a fresh day today I have been testing all the vesrions from v2.19.1 to the latest v2.29.0

After testing all releases, the wrong behaviour starts from version v2.29.0, all the other releases looks correct, I am going to update the title and description.

@idsulik It looks like the same issue yes, the interpolation is being added after the merge, but during the merge it detects an empty context property and tries to fill it using the $PWD from the extended yaml (custom folder in my case) because it is the first one being parsed I guess.

[glours]

I confirm this the same as #12001 , so I close this issue to keep only one for collecting feedback