[BUG] COMPOSE_FILE is not consistent with "-f" option

[hdepalma]

Description

Using COMPOSE_FILE environment variable should have the same behavior as using "-f" option on the command line, but it is not the case with docker compose v2.24.2.

It was working as expected before my latest upgrade.

Steps To Reproduce

1. Create a simple project

$ tree -a /tmp/compose-test
/tmp/compose-test
├── compose.yml
└── .env

$ cat .env
TAG=v1.5

$ cat compose.yml 
services:
  web:
    image: "webapp:${TAG}"

2. Perform the following tests

• no COMPOSE_FILE nor -f option -> expected behaviour

$ cd /tmp/compose-test
$ docker compose config
name: compose-test
services:
  web:
    image: webapp:v1.5
    networks:
      default: null
networks:
  default:
    name: compose-test_default

• -f option only -> expected behaviour

$ cd /tmp
$ docker compose -f /tmp/compose-test/compose.yml config
name: compose-test
services:
  web:
    image: webapp:v1.5
    networks:
      default: null
networks:
  default:
    name: compose-test_default

• COMPOSE_FILE environment variable only -> broken

$ cd /tmp
$ export COMPOSE_FILE=/tmp/compose-test/compose.yml
$ docker compose config
WARN[0000] The "TAG" variable is not set. Defaulting to a blank string. 
name: compose-test
services:
  web:
    image: 'webapp:'
    networks:
      default: null
networks:
  default:
    name: compose-test_default

In the last test, .env file is read from the current directory instead of relative to the compose file.

Compose Version

Docker Compose version v2.24.2

Docker Environment

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

Server:
 Containers: 5
  Running: 3
  Paused: 0
  Stopped: 2
 Images: 112
 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: cgroupfs
 Cgroup Version: 1
 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: a1496014c916f9e62104b33d1bb5bd03b0858e59
 runc version: v1.1.11-0-g4bccb38
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
 Kernel Version: 4.18.0-513.11.0.1.el8_9.x86_64
 Operating System: Oracle Linux Server 8.9
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 30.86GiB
 Name: aklhdepalma
 ID: JBKX:I7XJ:POEY:BUSD:AUED:O4UT:CEIX:CYUK:TCBI:FKYF:TBVG:M2DR
 Docker Root Dir: /home/dev/workspaces/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 172.18.0.0/16, Size: 24

Anything else?

Not sure if #11412 will solve this issue.

[hdepalma]

I have pulled compose-go v2.0.0-rc.3, applied the changes under compose-spec/compose-go#553, built the lib and referenced it in docker compose before build. It does not solve the issue mentioned in this ticket.

[ndeloof]

Can you please give #11405 a try ?

[hdepalma]

Can you please give #11405 a try ?

I can confirm that applying the changes under #11405 fixes the issue.

Thanks / Merci :)

[ndeloof]

closed by #11405