[BUG] Interaction between `context: ..` and `dockerfile: symlink` makes docker-compose fail to open Dockerfile

[kovaxis]

Description

Using a manual dockerfile: symlink tag, where symlink is a symlink to a Dockerfile that lives outside the working directory (but inside the context directory) fails.

I think it's a bit clearer in the reproduction.

Steps To Reproduce

1. Create a directory structure like:

./
    source/
        compose.yaml
        Dockerfile
    linked/
        compose.yaml
        Dockerfile -> ../source/Dockerfile

2. Contents for ./source/compose.yaml:

services:
  mainservice:
    build:
      context: ../
      dockerfile: ./source/Dockerfile

3. Contents for ./linked/compose.yaml:

services:
  mainservice:
    build:
      context: ../
      dockerfile: ./linked/Dockerfile

3. Dummy contents for ./source/Dockerfile:

FROM alpine:latest

4. ./linked/Dockerfile is a symlink to ./source/Dockerfile.

5. Try docker compose up from ./source/. It works.

6. Try docker compose up from ./linked/. It fails:

➜ linked $ docker compose build
Compose can now delegate builds to bake for better performance.
 To do so, set COMPOSE_BAKE=true.
[+] Building 0.0s (1/1) FINISHED        docker:default
 => [mainservice internal] load build definition from Dockerfile        0.0s
 => => transferring dockerfile: 114B        0.0s
failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

Compose Version

docker compose version: Docker Compose version v2.35.1
docker-compose version: Not available

Docker Environment

Client: Docker Engine - Community
 Version:    28.1.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.35.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 12
  Running: 3
  Paused: 0
  Stopped: 9
 Images: 80
 Server Version: 28.1.1
 Storage Driver: overlay2
  Backing Filesystem: btrfs
  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: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.6-200.fc41.x86_64
 Operating System: Fedora Linux 41 (Workstation Edition)
 OSType: linux
 Architecture: x86_64
 CPUs: 22
 Total Memory: 14.97GiB
 Name: gris
 ID: fe61f2c8-a27a-4b60-bb11-066737c45e89
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

This is anecdotal, but I think I saw some nondeterministic behavior in the error messages. I can't get the error messages to change now, though.

[ndeloof]

maybe a duplicate for #12799