This commit adds progress output while waiting for `depends_on`
conditions to resolve. The initial output looks like so:
⠿ Container chbench-zookeeper-1 Waiting 0s
⠿ Container chbench-kafka-1 Waiting 0s
⠿ Container chbench-one-off Waiting 0s
Once all conditions have been resolved, the ouput looks like this:
⠿ Container chbench-zookeeper-1 Healthy 1.2s
⠿ Container chbench-kafka-1 Healthy 3.2s
⠿ Container chbench-schema-registry-1 Exited 4s
As shown above, `service_healthy` conditions result in a terminal status
of "Healthy" while `service_exited_successfully` conditions result in a
terminal status of "Exited".
Signed-off-by: Nikhil Benesch <nikhil.benesch@gmail.com>
The previous code would wait for dependencies to become healthy forever,
even if they'd become unhealthy in the meantime. I can't find an issue
report for this bug, but it was described in a comment on the PR that
introduced the `--wait` flag [0].
[0]: https://github.com/docker/compose/pull/8777#issuecomment-965643839
Signed-off-by: Nikhil Benesch <nikhil.benesch@gmail.com>
Added unsupported volume bind option SELinux label `:z` and `:Z` in v2.
It is a regression compared to v1 written in Python.
The v2 uses the compose-spec/compose-go to parse Compose YAML
specification files but there was missing support for volume bind option
SELinux label `:z` and `:Z` in parser. It is fixed in:
- https://github.com/compose-spec/compose-go/pull/213
It fixes#9072
References:
- https://docs.docker.com/storage/bind-mounts/#configure-the-selinux-label
Signed-off-by: Tymoteusz Blazejczyk <tymoteusz.blazejczyk@tymonx.com>
The `group_add` key is parsed correctly from a compose file, but it is not
passed into the `ContainerCreate` API call, thus the configuration does
not take effect. This commit fixes the issue by propagating the
configuration from Docker compose's ServiceConfig to Docker container's
HostConfig.
Signed-off-by: Lance Chen <hello@lancechen.tw>
Intermediate containers remain even when build succeeded
when building with classic way (i.e. not with buildkit).
Remove them when build succeeded like default behavior of docker build.
Signed-off-by: notok <noto.kazufumi@gmail.com>
When a service has 0 replicas to start, it don't try to create any
container. However `composeService.startService()` still gets executed.
This method checks if there's been containers created for that service
beforehand. If there's none, it returns the following error: `no
containers to start`.
This change checks if replicas == 0 and exits early from
`composeService.startService()` when that's the case.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Fixes#8747
When the event is a container destroy, calling ContainerInspect returns
an error, because the container no longer exists. This causes both
`docker-compose up` and `docker-compose logs -f` to exit when removing a
stopped container.
This container has already emitted its die event, and has already been
cleaned up. I believe all that needs doing in this case is to early-out.
Signed-off-by: Stephen Thirlwall <sdt@dr.com>
Yuri Kanivetsky
Nikhil Benesch
Tymoteusz Blazejczyk
Lance Chen
Ulysses Souza
Ulysses Souza
Nicolas De Loof
notok
Kevin Roy
Guillaume Lours
Mathieu Champlon
Kyungsik Park
Albin Kerouanton
Pierre-Antoine Guillaume
Stephen Thirlwall