Allow running docker-compose up without specifying files

[millimoose]

We have our docker-compose.yml files structured according to the example in the Docker configuration here: https://docs.docker.com/compose/extends/

That is, there's a docker-compose.yml that sets up the "production" stage, and a docker-compose.override.yml for the "development" stage. The default behaviour for Docker Compose, when given no -f parameters, is to use these two configuration files for commands. The idea is that in development, one only needs to run docker-compose up without having to remember to use a specific file, to keep docker-compose.yml clean of development environment concerns while reusing it as much as possible.

Unfortunately it's currently impossible to fire up the containers using the plugin, because it doesn't support selecting multiple files yet (see #186); but it also doesn't seem to support selecting no configuration files which would work just as well in my case. For development it only really works if I duplicate all my configuration in a docker-compose.dev.yml and set that explicitly, which is a workaround I'd really like to avoid.

[StephenWeatherford]

This might have been fixed...

[PrashanthCorp]

Hi @millimoose, I have a couple of notes:

1. Previously, the multi-select was enabled in the form of a separate docker-compose up for each selected docker-compose file. See this block of code.
   We have a regression on that regard, and I'm working on fixing it.
   This would work differently from docker-compose -f docker-compose.yml -f docker-compose.prod.yml up --build right?
2. If we enable multi-selection, we also need to capture the order in which you compose process is carried out, because docker-compose -f docker-compose.yml -f docker-compose.prod.yml up --build is different from docker-compose -f docker-compose.prod.yml -f docker-compose.yml up --build. I don't see any good way to do this via usual UI input methods.
3. How often do you define a new sequence of compose files? Asking around, it felt like users usually have one pipeline for dev (docker-compose, docker-compose-override); one for test (docker-compose, docker-compose-override, docker-compose-test); and one for prod (docker-compose, docker-compose-override, a prod.yml that overwrites some URL endpoints and access keys). Is it around the same in your case?

[LazerFX]

Hi, I was brought in from #186, which I'd contributed to via comments. Thanks to @PrashanthCorp for pointing me in this direction.

For me, I'd consider that the order that I selected the files in, would then naturally flow into the order that the files were passed to docker-compose.

As I mentioned in #186 as well, most times I've seen docker-compose files, they are naturally segregated into less-then-more specific (i.e. docker-compose.yml then docker-compose.vs.debug.yml and so on).

As to the pipeline processes, the processes we were using were set up by Visual Studio 2017's Docker project - so two (debug and release environments) - a base docker-compose and a vs.debug and vs.release files that layer on top.

Happy to help in any way I can :D

[millimoose]

Hi @PrashanthCorp, thank you for taking a look at the issue. I'll grant that I'm not familiar with the usages of Docker you bring up, I made the issue motivated by being unable to follow the pattern for splitting "production" and "development" environments that Docker itself supports out of the box by automatically defaulting to -f docker-compose.yml -f docker-compose.override.yml.

If even more varied configurations are in common use, that's all the more reason to ditch the current UI, since it's going to cover very few real-world needs. That said, in my case, I only ever needed the pipeline above, so I'd guess defining new pipelines is a rareish occurence.

One aside: I don't believe you're "supposed to" (again, I don't have extensive Docker experience and real world best practices might be different) use -f docker-compose.yml -f docker-compose.override.yml -f docker-compose.prod.yml - my understanding was that docker-compose.yml was supposed to be the primary configuration file, and docker-compose.override.yml would replace services in it with their dev versions. (E.g. ones that don't copy application sources into the image, but mount it as a volume so you can live-reload.) At the very least you would just omit such an override file in production.

[PrashanthCorp]

I had a look at how VS does it: microsoft/DockerTools#121 (comment)

The sketch addresses the issue of specifying the order of compose files. I'll go ahead and take that approach for the fix. Let me know if the above comment needs some tweaking for your use-cases.

[ravipal]

#1603 allows running docker-compose commands without specifying the files as input.
But the extension still doesn't support running docker-compose with specific set of input files (base, override, another override).

[bwateratmsft]

Hey @millimoose , this is now available in Docker extension version 1.0.0.