You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
On CircleCI when trying to turn of the docker services we get the following error:
⠿ Network nitro_default Error 0.0s
failed to remove network nitro_default: Error response from daemon: error while removing network: network nitro_default id 721f08eff5d7191f2ef11bf59cc948273a129da596a1d51a032395a616dbe4f2 has active endpoints
Exited with code exit status 1
I've seen this locally couple of times as well, but there it can't be reproduced reliably.
To Reproduce
On my mac I'm not able to reproduce this all the time. But on circleCI it happened with the following steps:
test-node.bash --init --detach
and then try to turn all containers off with:
docker-compose -f docker-compose.yaml down
We found the following workaround on circleCI:
image_id=$(docker ps --filter "ancestor=nitro-testnode-scripts" --format "{{.ID}}")
if [[ ! -z $image_id ]]; then
docker stop $image_id
fi
Basically there is one runscripts container still being active. My guess is that docker compose down for some reason misses it and when it tries to destroy the network that container is preventing it.
Expected behavior
Expecting docker compose down to work without any glitches.
The text was updated successfully, but these errors were encountered:
Describe the bug
On CircleCI when trying to turn of the docker services we get the following error:
⠿ Network nitro_default Error 0.0s
failed to remove network nitro_default: Error response from daemon: error while removing network: network nitro_default id 721f08eff5d7191f2ef11bf59cc948273a129da596a1d51a032395a616dbe4f2 has active endpoints
Exited with code exit status 1
I've seen this locally couple of times as well, but there it can't be reproduced reliably.
Here is the circleCI run where it fails:
https://app.circleci.com/pipelines/github/beamer-bridge/beamer/3163/workflows/89e522df-aa09-4a60-9442-ffaa6ed92915/jobs/29965
To Reproduce
On my mac I'm not able to reproduce this all the time. But on circleCI it happened with the following steps:
and then try to turn all containers off with:
We found the following workaround on circleCI:
Basically there is one runscripts container still being active. My guess is that docker compose down for some reason misses it and when it tries to destroy the network that container is preventing it.
Expected behavior
Expecting
docker compose down
to work without any glitches.The text was updated successfully, but these errors were encountered: