support --env-file in docker-compose run command
NOTE: this is different than the .env file that is read by docker-compose commands and used for substitutions in the composition file... first mentioned here: https://github.com/docker/compose/issues/6170#issuecomment-673914083
We generate an env file that we would like to include via the docker-compose run command. e.g.
echo "FOO=bar" > vars.env
docker-compose run --env-file=vars.env --rm test-service
docker run supports this flag and it would be great if we saw docker-compose run maintain parity.
Is there planned support for this feature -- or will it be implemented in composev2 / "docker
our generated vars file is cumbersome (with multiline values) and relatively complicated to convert to various -e FOO=bar flags...
thanks!
@chris-crone @ndeloof Hi guys, I would like to work on this issue. I am not new to Go lang.
I have got a question. If I pass --env-file option to run command then should we append that to env-file provided as part of service config in docker-compose.yaml file or should we override them?
In meantime I've created a draft PR which assumes that if you pass --env-file from CLI it overrides the env-file specified in docker-compose.yaml file. I will update PR as per your suggestion if we should append them.
@chris-crone @ndeloof @ulyssessouza Friendly ping.
I would think would want to append the --env-file(s) passed via the cli to any included in the service's definition. appending would override any previously defined keys.
I'm surprised this issue hasn't more discussions.
Just had this case in a project and that's a deal breaker, will have to generate a huge docker run command just because of that issue
I think there's a misconception with the original --env-file option which should never have the same name than docker's --env-file.
Now the topic is stuck because it may conflict with the original --env-file
What about a --env-from instead?
That's indeed sad this flag name was selected, but this is the legacy we have to deal with.
We could use --service-env-file or something comparable, even verbose, to workaround this ambiguity
@ndeloof I have updated the PR with changes suggested.