Compose DevServices should start the missing containers #51699
Description
Description
When starting compose devservices without any previous startup, the containers get run successfully.
However, if any container for that compose project is found, on subsequent runs, then ALL containers are assumed to be running already. It would be much better if we could just start the missing containers, if any, by taking advantage of the idempotency of "docker compose up" by default, not starting containers that are already started .
Some use cases:
= container fails =
- start some app with quarkus dev
- container X fails (internal reason) but Y continues (from the compose file)
- stop some app
- start the same app with quarkus dev again => container X does not start / restart, which is a pitty. nor does it complain by default
= additional containers =
- start some app with quarkus dev (and using shared/reused containers with compose)
- start another app with quarkus dev , but has one more quarkus compose profile
- container X and Y from start of the first app are detected, no other containers start for the new profile of the second application
= testing =
- variation of "additional containers",
- running quarkus dev in some app, and reuse = true (stop-containers = false)
- stop quarkus dev in some app
- run quarkus tests on another app
- another app's tests need container Z (from a different profile)
- container Z is not started because X and Y were detected because of the previous start of some app at step 2 (only true when reuse-project: true for tests)
Implementation ideas
Just do composeProject.start() always!
If build => docker build cache will trigger, not a big problem
If build or no build => docker compose up -d is already idempotent, so it doesn't start containers that did not change.
It should be quite easy to implement...