I’m migrating from compose v1 to v2 and I noticed that COMPOSE_PROFILES=foo in .env now seems to take precedence over --profile on the command line.
Is this intentional? If yes then it makes my setup more awkward to use:
COMPOSE_PROFILES=all in .env
all services are in profile all
with v1, users can choose another subset of services via docker-compose --profile x ...
with v2, I now have to use COMPOSE_PROFILES=x docker compose ... as --profile doesn’t work anymore (until I remove COMPOSE_PROFILES from .env)
Version is 2.10.2, as per latest Docker Desktop for Windows (actual usage is within WSL2).
I don’t know if it was intentional. I rarely use profiles with Docker Compose, but if you feel it can be a bug, I think the best place to report it would be on GitHub:
Even if it was intentional, if the variable can override the --profile options, there should be a warning at least. It could be similar to when you get a waning about undefined variables.
Just came here since I’m having the similar issue with the --profile as we use that a lot here in work for different composing options. Stopped working when spinning down on v2.