support --env-file in docker-compose run command

[briceburg]

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: #6170 (comment)

---

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 compose" ?

our generated vars file is cumbersome (with multiline values) and relatively complicated to convert to various -e FOO=bar flags...

thanks!

[KoditkarVedant]

@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?

[KoditkarVedant]

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.

[KoditkarVedant]

@chris-crone @ndeloof @ulyssessouza Friendly ping.

[briceburg]

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.

[reggermont]

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?

[ndeloof]

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

[KoditkarVedant]

@ndeloof I have updated the PR with changes suggested.