ndeloof
commented
1 year ago There's unfortunately no way to declare your setup service isn't actually a service, and termination is expected.
Open nmguse-bighealth opened 1 year ago
ndeloof
commented
1 year ago There's unfortunately no way to declare your setup service isn't actually a service, and termination is expected.
mvejmelk
commented
1 year ago Hit this as well - does anyone have some workaround, please?
olek-p
commented
1 year ago Hit this as well - does anyone have some workaround, please?
I'm using this:
docker-compose -f docker-compose.yml up --wait || truedocker-compose -f docker-compose.yml up --wait || true
We use the docker compose as part of test setup - the or-true approach will effectively void ANY kind of error coming from the stack (not only the "harmless one").
olek-p
commented
1 year ago docker-compose -f docker-compose.yml up --wait || true
We use the docker compose as part of test setup - the or-true approach will effectively void ANY kind of error coming from the stack (not only the "harmless one").
Yes, it will. It will also make your test setup complete without errors (until this issue is fixed). The choice is yours :)
douardda
commented
8 months ago There's unfortunately no way to declare your
setupservice isn't actually a service, and termination is expected.
what about just using the return code of the "pseudo service" process? if it's 0, then do not consider it as an error by the compose up --wait command.
luciangabor
commented
8 months ago While this is not to argue that --wait couldn't/shouldn't take into account the exit code of services that exit (with the "complications" given by a restart policy taken into account), and with the observation that it's kinda' like that already:
$ docker compose -f - up --wait <<'EOF'
services:
sleepy:
image: alpine
command: sleep 5
EOF
[+] Running 1/1
✔ Container waitish-sleepy-1 Healthy
$ echo $?
0
... there is also this page of documentation: https://docs.docker.com/compose/profiles/#auto-starting-profiles-and-dependency-resolution
Well, noting that ... there is an unfortunate limitation - run can only run one service - and ... extrapolating a bit, here's an example of what works now:
# compose.yaml
services:
postgres:
image: postgres
environment:
POSTGRES_PASSWORD: password
healthcheck:
test: pg_isready
start_interval: 1s
start_period: 30s
psql:
profiles:
- .init
image: postgres
depends_on:
postgres:
condition: service_healthy
environment:
PGUSER: postgres
PGDATABASE: postgres
PGPASSWORD: password
entrypoint: psql -h postgres
command: -c \\conninfo
init:
profiles:
- .init
build:
dockerfile_inline: FROM scratch
init: true
entrypoint: /sbin/docker-init --version
depends_on:
psql:
condition: service_completed_successfully
$ docker compose run init
[+] Creating 3/3
✔ Network init_default Created 0.1s
✔ Container init-postgres-1 Created 0.1s
✔ Container init-psql-1 Created 0.1s
[+] Running 2/2
✔ Container init-postgres-1 Healthy 5.8s
✔ Container init-psql-1 Started 0.3s
tini version 0.19.0 - git.de40ad0
$ echo $?
0
# postgres is started because of the init -> psql -> postgres depends-ons
# and init could depend on a number of other services/"tasks"/one-offs
# the alternative would be to run each needed "task"/one-off sequentially, but that requires remembering them
$ docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
init-postgres-1 postgres "docker-entrypoint.s…" postgres 2 minutes ago Up 2 minutes (healthy) 5432/tcp
# next, up --wait, could start the rest and it would ignore psql and init because they are behind a profile;
# it could even be done by the init itself if you can assume enough (e.g. about docker's sock)
$ docker compose up --wait
[+] Running 1/1
✔ Container init-postgres-1 Healthy
$ echo $?
0
# PS
$ docker compose --profile .init logs psql
psql-1 | You are connected to database "postgres" as user "postgres" on host "postgres" (address "172.28.0.2") at port "5432".
gmile
commented
8 months ago Just hit this too and confirmed this is still a problem as of 2.24.7. This thread doesn't seem to lack examples, but I'll include mine just in case too.
pkoutsovasilis
commented
8 months ago FWIW I opened this PR and your example @gmile executes successfully with --wait-allow-exit
pkoutsovasilis
commented
8 months ago @ndeloof who could be an appropriate reviewer for the PR mentioned above, ty 🙂
idsulik
commented
2 months ago what about this format docker compose up --wait-services my-service1,my-service2? we can specify what services we want to wait. Implemented it here https://github.com/docker/compose/pull/12172
jvitor83
commented
2 months ago @idsulik
Not sure if this can help, but you can control which one you dont want to consider inside the compose by using the attach: false in the services.
idsulik
commented
2 months ago @jvitor83
Not sure if this can help.
why? docker compose up --wait-services postgres it will wait for the postgres service and ignore the postgres_setup service
Description
When using
docker compose up --wait, where I have an init container that populates some data and then exits (0), docker compose will exit 1.If any other container depends on the init container finishing, it will exit properly, as described/exampled in this PR: https://github.com/docker/compose/pull/9572. In my situation however, there is no container that runs a service that depends on the init container finishing.
Steps To Reproduce
docker-compose.yml example:
Run docker compose/print exit code:
Compose Version
Docker Environment
Anything else?
No response