Docker API respond with status code conflict, container xxxxxx is not running

Question

When running dotnet test inside a gitlab cicd pipeline with the package testcontainer, containers are started but this error appears :

Error Message:
   Docker.DotNet.DockerApiException : Docker API responded with status code=Conflict, response={"message":"Container 3371da42d9447805eb7d5d7ef2da7b5c8395b5c333e181d4add422205256e49a is not running"}

I'm using in my pipeline docker socket binding instead of docker dind, as the documentation use docker dind i would like to now if it should also work with docker socket binding.

docker in gitlab ci documentation

I would like to now if testcontainer as it is using gitlab runner docker, they should be mount in parallels and maybe are not accessible from inside the job container.

Neela

Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking. – Ingrowth

Answer 1

When you run GitLab pipelines with docker:dind services each job gets its own, isolated docker instance that it can do builds in, and if it does, create its own private containers in.

bind mounting the /var/run/docker.sock means all the gitlab jobs, especially if you have multiple runners or concurrency > 1, share the same docker environment on the host and they can easily conflict if they try to create named objects. the obvious pro is they share a build cache so this approach potentially yields much better build times.

If you can guarantee that there is only one runner and concurrency is 1, then it should be safe to do docker container prune -f as a before_script step to clean up any lingering containers left from previous job runs.

But, in this case, it seems like it might be better for the testcontainers jobs to explicitly use docker:dind as a service even if your other jobs use the shared socket. Either declare two runners in the config.toml, one to do "docker" tags the other to do "docker:dind" tags and set them up as appropriate. Or just set up one runner as normal with privleged mode enabled, and then declare a docker:dind service per job that needs it.

Moule

Answer 2

If you got here because your SqlContainer tests randomly started to fail like ours. It's not your fault. Seems like there's something up with the ubuntu-latest github runner and someone has found a workaround.

https://blog.rufer.be/2024/09/22/workaround-fix-testcontainers-sql-error-docker-dotnet-dockerapiexception-docker-api-responded-with-status-codeconflict/

Info from TestContainers

https://github.com/testcontainers/testcontainers-dotnet/pull/1265

Bug/Pr on TestContainers to fix it, maybe?

https://github.com/testcontainers/testcontainers-dotnet/issues/1274 https://github.com/testcontainers/testcontainers-dotnet/pull/1270/files

Hypnosis