-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Regressions in .env loading #11823
Comments
This topic is a never ending issue it seems :'( As For your scenario, I would recommend to use an explicit |
I don't understand; it looks like the original behavior (read both Furthermore, the original behavior did not have the chicken-and-egg problem that you describe, since it was possible to:
Or am I missing something? The current behavior (read only the top-level |
Actually compose v1 only used the local |
Also to be mentioned: the logic you describe (read the local |
Description
The way
.env
files are loaded has changed twice recently.Let's assume the following project structure:
When running
docker compose
in thesub/
directory, ....env
files, with the top-level.env
file taking precedence over the sub-level one.env
file in the current directory, and ignore the one at the top level.env
file at the top-level directory, and ignores the one in the sub directoryBoth changes broke some folks' workflows in different ways (see #11531 and #11575). The second change might be related to #11405 but I haven't looked at the code, so I might be wrong.
Steps To Reproduce
Here is the output with various versions of Compose...
Up to Compose 2.23.3:
From Compose 2.24 to 2.24.5:
From Compose 2.24.6:
Compose Version
Docker Environment
Anything else?
The ability of loading a
.env
file from the current directory (instead, or in addition to, the top-level.env
file) is very powerful.Example user story: I develop an application stack made of 2 services,
service1
andservice2
. I sell that stack as a SAAS to multiple customers. Each customer gets their own stack, with their own instance of each service. I want to deploy each stack with Compose and follow "DRY" principles: I want to avoid repeating or duplicating code as much as possible.I can achieve that with the following structure:
The
.env
files in thecustomerX
directories set customer-specific information (credentials, plan limits, etc.) and they also setCOMPOSE_PROJECT_NAME
to a unique value.That way, to manage the stack for
customerX
, all I have to do is go to their specific directory and rundocker compose
command. I don't need to set environment variables - and more importantly, I don't risk forgetting to set a critical environment variable or command-line flag before manipulating a customer environment.The text was updated successfully, but these errors were encountered: