[BUG] Building a service image fails for service extending a definition from different directory #10798
Description
Description
I am trying to start a service that extends another service in different location when the base service has its build definition with context ./relative-path-to-context.
I am getting the following error.
unable to prepare context: path "./relative-path-to-context" not found
I would expect the path to be resolved relative to the file with base service definitions rather than to the file that extends the base service.
Steps To Reproduce
- Prepare a base service
./base/docker-compose.ymlservices: foo: image: foo build: ./foo
./base/foo/DockerfileFROM node:latest RUN touch foo.txt
- Extend the base service (from a composition file in different location)
./custom/docker-compose.ymlservices: foo: extends: file: ../base/docker-compose.yml service: foo
- Run
docker compose buildin./custom - See the error
unable to prepare context: path "./foo" not found
Compose Version
Docker Compose version v2.19.1
Docker Environment
Client:
Version: 24.0.2
Context: desktop-linux
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.11.0
Path: .../.docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.19.1
Path: .../.docker/cli-plugins/docker-compose
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: .../.docker/cli-plugins/docker-dev
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.20
Path: .../.docker/cli-plugins/docker-extension
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v0.1.0-beta.6
Path: .../.docker/cli-plugins/docker-init
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: .../.docker/cli-plugins/docker-sbom
scan: Docker Scan (Docker Inc.)
Version: v0.26.0
Path: .../.docker/cli-plugins/docker-scan
scout: Command line tool for Docker Scout (Docker Inc.)
Version: 0.16.1
Path: .../.docker/cli-plugins/docker-scout
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 8
Server Version: 24.0.2
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: cgroupfs
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 3dce8eb055cbb6872793272b4f20ed16117344f8
runc version: v1.1.7-0-g860f061
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 5.15.49-linuxkit-pr
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.773GiB
Name: docker-desktop
ID: bc6a0a07-c70f-4c27-99a5-863c7ee5b8d8
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
Experimental: true
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
Anything else?
I have observed the same behaviour on version 2.19.0 but it worked on version 2.18.1.