gaetanBloch
commented
1 year ago Hello,
Any update on this enhancement? It is indeed frustrating. Is there any way to force the retry mechanism?
Open cbreezier opened 1 year ago
gaetanBloch
commented
1 year ago Hello,
Any update on this enhancement? It is indeed frustrating. Is there any way to force the retry mechanism?
eddumelendez
commented
1 year ago Sometimes testcontainers fails to start due to a Docker environment not existing
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?
Birne94
commented
1 year ago 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.
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 Previous attempts to find a Docker environment failed. Will not retry.. The fix for podman is easy, I do podman machine stop && podman machine start and it is running again. However in order for the testcontainers to work again, I have to somehow get rid of the gradle cache or processes.
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 build.gradle) would be nice.
cbreezier
commented
1 year ago I do not expect this to be a very often issue.
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.
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?
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.
hadson172
commented
1 year ago This issue is really annoying. Wasting a lot of time for this. Any updates ?
cbreezier
commented
1 year ago I ran into this problem again. I dug around and found some background - this feature was introduced in https://github.com/testcontainers/testcontainers-java/pull/456 and it works by caching the lack of Docker environment in a static final AtomicBoolean FAIL_FAST_ALWAYS. There is no way to change this back to false once it's been set to true.
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 gradle --stop (see https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:stopping_an_existing_daemon). Or in my case, ./gradlew --stop. You can also use ./gradlew --status to view the existing daemon(s).
I'd like to raise a PR to add this workaround to the failure message.
monosoul
commented
11 months ago 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
kevinm416
commented
10 months ago Workaround if you're using testcontainers as part of a gradle build:
import org.testcontainers.dockerclient.DockerClientProviderStrategy
buildscript {
...
dependencies {
...
// Whatever brings in DockerClientProviderStrategy for your project
classpath "org.springframework.boot:spring-boot-testcontainers:3.1.5"
}
}
// Groovy doesn't care about `private`.
DockerClientProviderStrategy.FAIL_FAST_ALWAYS.set(false)
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.