Hello @ndeloof. I've run some tests on your branch and I've found some possible issues that I wanted to let you know. If I should instead report this as part of the original issue ticket, please let me know, okay?

Test 1

version: "2.4"
services:
  # Long-lived container.
  hello1:
    image: "alpine"
    command: ["sh", "-c", "echo 'Long-lived container, no health check'; sleep 1h;"]

  # Short-lived container.
  hello2:
    image: "alpine"
    command: ["echo", "Short-lived container, no health check"]

Execution:

$ compose --file docker-compose-mixed-nohc.yml up --detach --remove-orphans --wait
[+] Running 2/3
 ⠿ Network aktualizr-tests_default     Created                                                    0.0s
 ⠿ Container aktualizr-tests-hello2-1  Waiting                                                   15.8s
 ⠿ Container aktualizr-tests-hello1-1  Started                                                    0.4s
Killed
(compose is an alias to docker-compose)

Hitting ^C did not stop docker-compose which had to be killed.

Test 2

version: "2.4"
services:
  # Short-lived container.
  hello:
    image: "alpine"
    command: ["echo", "Short-lived container, no health check"]

Execution:

$ compose --file docker-compose-shortlife-nohc.yml up --detach --remove-orphans --wait
[+] Running 1/2
 ⠿ Network aktualizr-tests_default    Created                                                    0.0s
 ⠿ Container aktualizr-tests-hello-1  Waiting                                                    0.8s
container aktualizr-tests-hello-1 exited (0)

$ echo $?
1

Notice in this case the --wait didn't cause docker-compose to wait forever, but the exit code of the program was non-zero indicating something went wrong.

Test 3

# Run multiple short-lived containers.
version: "2.4"
services:
  hello1:
    image: "alpine"
    command: ["echo", "Short-lived container (1), no health check"]
  hello2:
    image: "alpine"
    command: ["echo", "Short-lived container (2), no health check"]
  hello3:
    image: "alpine"
    command: ["echo", "Short-lived container (3), no health check"]

Execution:

$ compose --file docker-compose-shortlife-nohc3.yml up --detach --remove-orphans --wait
[+] Running 3/4
 ⠿ Network aktualizr-tests_default     Created                                                          0.0s
 ⠿ Container aktualizr-tests-hello1-1  Waiting                                                         26.9s
 ⠿ Container aktualizr-tests-hello2-1  Started                                                          0.5s
 ⠿ Container aktualizr-tests-hello3-1  Started                                                          0.6s
Killed

Like with Test 1, hitting ^C did not stop docker-compose which had to be killed.

@rborn-tx thanks, nice feedback. I'll try to convert those examples into e2e tests so we have better coverage for this feature

I fixed reported corner cases.
For second one ("Test 2") service command immediately complete, --wait detect container exited and report failure to become "running". This sounds a reasonable behavior as service is expected to run until interrupted, not to complete this way (otherwise, --wait makes no sense)

Codecov Report

Base: 73.89% // Head: 73.89% // No change to project coverage 👍

Coverage data is based on head (b8b02d6) compared to base (e908f41).
Patch has no changes to coverable lines.

❗ Current head b8b02d6 differs from pull request most recent head 52478f0. Consider uploading reports for the commit 52478f0 to get more accurate results

@@           Coverage Diff           @@
##               v2   #10209   +/-   ##
=======================================
  Coverage   73.89%   73.89%           
=======================================
  Files           2        2           
  Lines         272      272           
=======================================
  Hits          201      201           
  Misses         60       60           
  Partials       11       11           

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

I fixed reported corner cases. For second one ("Test 2") service command immediately complete, --wait detect container exited and report failure to become "running". This sounds a reasonable behavior as service is expected to run until interrupted, not to complete this way (otherwise, --wait makes no sense)

I disagree. I have multiple services in my docker-compose.yml, that I do want compose to wait for. At the same time I have a service that does its job and exits with 0 code. This change broke my setup and I had to add artificial sleep at the end of the script. I think --wait should take into account the restart option and not error out in Test 2.

In other words: Test 1 should pass, but it now errors out with container test-hello2-1 exited (0)

@kaos14 we miss an explicit way to define "jobs" or "tasks", i.e. container that are EXPECTED to complete

@ndeloof What did you mean "I fixed reported corner cases."? None of them works in 2.16. Is this as expected?