You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What's a good approach to having a dcproj that uses a different base compose file that includes fewer services?
I tried copying the dcproj and docker-compose.yml, renaming to be unique, changing ProjectGuid, and then commenting out the unwanted services.
When I start the second project, it still runs docker-compose.yml
I saw an issue about having multiple projects, but the way it's described as being implemented, the base docker-compose.yml is still executed: #121
"The order of execution in any docker-compose command will be as follows:
{docker-compose main file} {docker-compose override file} [Additional compose files]* {generated files}"
I'm not sure how I'd use an additional compose file to remove services from the base one the way this is being overlayed?
It seems surprising that a dcproj that doesn't reference docker-compose.yml still runs it. Just my opinion, but this would be a little bit like a csproj file always looking for and compiling a Program.cs, even if one wasn't included in the project, just because it's a convention. If it is a convention, fine, let the project template add+reference one in a new project template, but that's where the convention should stop. If that default file is removed/excluded and a different one is added to the project, then don't try to run docker-compose since it is not referenced in the project. IMO the convention should be implemented in initial project generation from template, but execution/running project should be driven by what is actually referenced in the project so a dev can remove the docker-compose.yml and use a different base yml.
The text was updated successfully, but these errors were encountered:
If your goal is to sometimes run only some of the services, I recommend using subset of services feature.
If you feel that multiple compose files /projects are what you need then part 1 and 2 of this comment detail how to get that working. Most notably either putting the projects in separate folders or using DockerComposeBaseFilePath to differentiate the compose files used.
Is it possible to make the filename for docker-compose.vs.debug.yml and docker-compose.vs.release.yml which are use to override the {generated files}, follow DockerComposeBaseFilePath's value?
What's a good approach to having a dcproj that uses a different base compose file that includes fewer services?
I tried copying the dcproj and docker-compose.yml, renaming to be unique, changing ProjectGuid, and then commenting out the unwanted services.
When I start the second project, it still runs docker-compose.yml
I saw an issue about having multiple projects, but the way it's described as being implemented, the base docker-compose.yml is still executed: #121
"The order of execution in any docker-compose command will be as follows:
{docker-compose main file} {docker-compose override file} [Additional compose files]* {generated files}"
I'm not sure how I'd use an additional compose file to remove services from the base one the way this is being overlayed?
It seems surprising that a dcproj that doesn't reference docker-compose.yml still runs it. Just my opinion, but this would be a little bit like a csproj file always looking for and compiling a Program.cs, even if one wasn't included in the project, just because it's a convention. If it is a convention, fine, let the project template add+reference one in a new project template, but that's where the convention should stop. If that default file is removed/excluded and a different one is added to the project, then don't try to run docker-compose since it is not referenced in the project. IMO the convention should be implemented in initial project generation from template, but execution/running project should be driven by what is actually referenced in the project so a dev can remove the docker-compose.yml and use a different base yml.
The text was updated successfully, but these errors were encountered: