Nicolas De loof
Nicolas De loof
Only services indeed get recreated after configuration change has been detected. We could do the same for volumes (while bit more complex to manage regarding lifecycle) _but_ this would mean...
Let's keep this issue open in case this becomes popular, but to be honest I consider Docker Compose is doing way too much magic trying to guess the compose file...
Why not use the existing `docker --log-level=debug compose ...` feature ?
That's a documentation issue, `up` does not allow setting additional environment variables this way, this option is for `run` compose subcommand. The reason is that `up` target multiple containers, so...
addressed in https://github.com/docker/docs/pull/19481
> I don't see how one can argue that -e should not apply to up and simultaneously support that an environment file should. environment file applies to **interpolation**, not on...
> override a value in my .env file just do: ``` $ FOO=BAR docker compose up ``` shell environment have higher precedence setting the project reference variables
This would then be very confusing : What would you expect `docker compose -e FOO=BAR run -e FOO=BAZ service` to do?
variables in shell environment and `.env` file are used for interpolation in compose.yaml, they not **NOT** impact the container environment until you have explicitly configured your compose.yaml definition with some...
> If I have an .env that has API_KEY in it and my compose yaml uses it for a couple of containers, it seems reasonable that running up -e API_KEY="..."...