[BUG] Changed behaviour for default env-file path between v2.20.2 and v2.21.0

Adrien-Atmosphere commented 1 year ago

Description

I have a single compose file that defines multiple profiles. I have multiple sub-directories that contains .env file where the environment variable COMPOSE_PROFILES is defined. To start different profile configuration, I would basically go to the appropriate folder and launch docker compose up -d . Using docker compose version v2.20.2, the profiles defined in the .env file were properly used. But it is not working anymore in v2.21.0.

Could you please advise if my use case was an unintended behavior from the old versions?

Steps To Reproduce

Create a test directory as follow :

├── compose.yml
└── instance1
└── .env

compose.yml :

services:
  prof1:
    image: alpine
    profiles: ['profile1']
    command: ['sleep', 'infinity']
  prof2:
    image: alpine
    profiles: ['profile2']
    command: ['sleep', 'infinity']
  always:
   image: alpine
   command: ['sleep', 'infinity']
   init: true

instance1/.env :

COMPOSE_PROJECT_NAME=instance1
COMPOSE_PROFILES=profile1

Go to instance1 folder and docker compose up -d with docker compose version v2.20.2

[+] Running 2/2
✔ Container instance1-prof1-1   Started                                                                                                                                                               0.3s 
✔ Container instance1-always-1  Running

Do the same thing using docker compose version v2.21.0 :

[+] Running 1/0
✔ Container instance1-always-1  Running

Compose Version

Docker Compose version v2.21.0

Docker Environment

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

Server:
 Containers: 11
  Running: 11
  Paused: 0
  Stopped: 0
 Images: 86
 Server Version: 24.0.6
 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 logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 61f9fd88f79f081d64d6fa3bb1a0dc71ec870523
 runc version: v1.1.9-0-gccaecfc
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.2.0-33-generic
 Operating System: Ubuntu 22.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 15.01GiB
 Name: adrien-Latitude-5420
 ID: RGG6:FFJ6:VQQE:4GZH:AJCY:YEHD:ZMEW:47X4:KEBD:NAJZ:265M:BCFE
 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

ndeloof commented 1 year ago

While this indeed sounds like a regression we have to fix, you better should use --env-file instance1/.env to select the env file with required configuration, vs getting into a subfolder to run commands

ndeloof commented 11 months ago

The reason you get this behavior is due to project directory definition As you run command from instance1 folder, Docker Compose will search for a compose.yaml file, and then look into parent folder. This discovery also defines project directory as parent folder, and this is where a default .env file is also searched for (not in you command line working directory). This used to be the case in some earlier releases but this come with many other issues and weird behaviors. I'm closing this issue as "work as expected". As suggested, you can rely on --env-file to select an alternate env file to get profiles enabled

docker / compose