[BUG] With multiple Compose files `services[].build.context` is evaluated relative to the first one

[i-ky]

Description

According to docs services[].build.context is interpreted as follows:

When the value supplied is a relative path, it is interpreted as relative to the location of the Compose file.

I am expecting that in case of multiple Compose files by "the location of the Compose file" you mean "the location of the Compose file currently being parsed". But it seems that the location of the first Compose file is used instead.

Steps To Reproduce

$ pwd
/tmp/test

$ cat compose.yaml 

$ cat foo/compose.yaml 
services:
  foo:
    build:
      context: ./

$ docker compose --file compose.yaml --file foo/compose.yaml config
name: test
services:
  foo:
    build:
      context: /tmp/test
      dockerfile: Dockerfile
    networks:
      default: null
networks:
  default:
    name: test_default

Note that services.foo.build.context is /tmp/test. I am expecting it to be /tmp/test + foo/ (location of foo/compose.yaml) + ./ = /tmp/test/foo.

Compose Version

$ docker compose version
Docker Compose version v2.28.1

Docker Environment

$ docker info
Client: Docker Engine - Community
 Version:    27.0.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.15.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.28.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 8
  Running: 0
  Paused: 0
  Stopped: 8
 Images: 11
 Server Version: 27.0.3
 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: ae71819c4f5e67bb4d5ae76a6b735f29cc25774e
 runc version: v1.1.13-0-g58aa920
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.5.0-41-generic
 Operating System: Ubuntu 22.04.4 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 16
 Total Memory: 30.76GiB
 Name: redacted
 ID: 5f8d7612-5da9-4ce2-a156-9b2e1d694891
 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

[i-ky]

Related to:

1. #3874
2. #4851
3. #4857
4. #10043
5. #11944
6. https://github.com/compose-spec/compose-go/issues/335.

[i-ky]

After reading through related tickets I managed to find another relevant piece of documentation:

When you use multiple Compose files, you must make sure all paths in the files are relative to the base Compose file (the first Compose file specified with -f).

...and

When you use multiple Compose files, all paths in the files are relative to the first configuration file specified with -f. You can use the --project-directory option to override this base path.

This suggests that the described behaviour is intentional.

Nevertheless, I think it would make sense to adjust the piece I quoted above:

When the value supplied is a relative path, it is interpreted as relative to the location of the Compose file.

...because it is misleading or ambiguous at best.

[ndeloof]

this indeed is a docs issue. . is always resolved relative to the project directory

[thaJeztah]

Proposal related to this;

• https://github.com/compose-spec/compose-spec/issues/248

[i-ky]

this indeed is a docs issue.

@ndeloof, thank you for confirming this! Can I leave it to you to reclassify the issue as a docs issue instead of bug (and possibly move to a more appropriate repo)?