[Enhancement]: Improve "Previous attempts to find a Docker environment failed. Will not retry." error #6441
Comments
|
Hello, Any update on this enhancement? It is indeed frustrating. |
I do not expect this to be a very often issue. It could be an issue when setting a new machine or the CI pipeline. After that, testcontainers should run smoothly. At least, that has been the experience, so far. Just want to make sure I understand your issue, but are you suggesting retries to detect the docker environment once the test suite is running? |
eddumelendez
added
the
resolution/waiting-for-info
I am having the same issue. Due to company policy, we are using podman on our local machines and from time to time the VM becomes unresponsive. In this case the testcontainers fail and I get From my side the expectation would be that the docker environment (or lack of it) is not cached at all, I don't think finding the docker socket or host is something that takes so much time that it requires caching. Alternatively, being able to disable the caching on a project level (e.g. in |
I don't start the Docker daemons on my local development machine on startup. If I ever run a test using testcontainers without starting Docker, I run into this issue, and then I have to close all my programs and restart my computer in order to try again.
No, nothing quite so complicated. I'd just like to see that testcontainers doesn't cache the information that "Docker environment could not be found" so that I can:
Currently, if I ever accidentally run anything that uses testcontainers without a Docker environment present, it essentially locks me out of running anything that uses testcontainers ever again until a full restart. |
|
This issue is really annoying. Wasting a lot of time for this. Any updates ? |
|
I ran into this problem again. I dug around and found some background - this feature was introduced in #456 and it works by caching the lack of Docker environment in a However, I did also find a workaround - stopping the gradle daemon causes any instantiated classes to be uninstantiated (obviously) and we can reset the cached failure that way. You can stop the daemon simply with I'd like to raise a PR to add this workaround to the failure message. |
|
Here's a small snippet to help workaround that issue: import org.testcontainers.dockerclient.DockerClientProviderStrategy
import java.util.concurrent.atomic.AtomicBoolean
import kotlin.reflect.KCallable
import kotlin.reflect.full.declaredMembers
import kotlin.reflect.jvm.isAccessible
val failFastAlways = DockerClientProviderStrategy::class.declaredMembers
.single { it.name == "FAIL_FAST_ALWAYS" }
.apply { isAccessible = true }
.let {
@Suppress("UNCHECKED_CAST")
it as KCallable<AtomicBoolean>
}
.call()
failFastAlways.set(false)Usage example can be found here: monosoul/jooq-gradle-plugin#152 |
Adds a workaround for testcontainers/testcontainers-java#6441 issue. The issue happens when Docker was unavailable during the first attempt to start a container. All future attempts will fail, since `testcontainers` caches the connection attempt result in a static variable, so the state will persist while the class is loaded. The workaround is to reset the state through reflection each time before we start the container.
|
Workaround if you're using testcontainers as part of a gradle build: |
|
It's already a year. Probably time to merge already |
|
Closing for the reason leave at the PR #7533 (comment) |
|
in case someone elses faces this issue on maven when running docker via rancher. I solved it via:
|
|
FWIW, if using sudo ln -s $HOME/.colima/docker.sock /var/run/docker.sockNo other actions necessary. |
Module
Core
Proposal
Sometimes testcontainers fails to start due to a Docker environment not existing. When this happens, the user will get an error similar to:
The problem is that testcontainers refuses to retry finding a Docker environment, even after the user fixes the issue on their machine. There appears to be no way to force a retry, short of a nuclear option like restarting the computer or force killing all gradle daemons.
Why does it not retry on subsequent attempts? It's a very frustrating behaviour.
The text was updated successfully, but these errors were encountered: