Could not find a valid Docker environment. And no attempted configurations?

[mpiggott]

Testcontainers Java 1.17.6

I've run into an issue with starting a custom docker image as a testcontainer when running on the build server (locally on Linux it works). Oddly, we use a PostgreSQL testcontainer in this particular test without issue. Further the custom image itself is verified itself via java testcontainers in its own build.

I've enabled debug logging for org.testcontainers and com.github.dockerjava but all I get for output is:

2023-02-16 15:14:13,213+0000 DEBUG [RMI TCP Connection(1)-127.0.0.1] *SYSTEM org.testcontainers.utility.TestcontainersConfiguration - Testcontainers configuration overrides will be loaded from file:/jenkins/.testcontainers.properties
2023-02-16 15:14:13,220+0000 WARN  [RMI TCP Connection(1)-127.0.0.1] *SYSTEM org.testcontainers.utility.TestcontainersConfiguration - Attempted to read Testcontainers configuration file at file:/jenkins/.testcontainers.properties but the file was not found. Exception message: FileNotFoundException: /jenkins/.testcontainers.properties (No such file or directory)
2023-02-16 15:14:13,223+0000 INFO  [RMI TCP Connection(1)-127.0.0.1] *SYSTEM org.testcontainers.utility.ImageNameSubstitutor - Image name substitution will be performed by: DefaultImageNameSubstitutor (composite of 'ConfigurationFileImageNameSubstitutor' and 'PrefixingImageNameSubstitutor')
2023-02-16 15:14:13,246+0000 ERROR [RMI TCP Connection(1)-127.0.0.1] *SYSTEM org.testcontainers.dockerclient.DockerClientProviderStrategy - Could not find a valid Docker environment. Please check configuration. Attempted configurations were:
As no valid configuration was found, execution cannot continue.
See https://www.testcontainers.org/on_failure.html for more details.

java.lang.IllegalStateException: Could not find a valid Docker environment. Please see logs and check configuration
	at org.testcontainers.dockerclient.DockerClientProviderStrategy.lambda$getFirstValidStrategy$7(DockerClientProviderStrategy.java:256)
	at java.util.Optional.orElseThrow(Optional.java:290)
	at org.testcontainers.dockerclient.DockerClientProviderStrategy.getFirstValidStrategy(DockerClientProviderStrategy.java:247)
	at org.testcontainers.DockerClientFactory.getOrInitializeStrategy(DockerClientFactory.java:150)
	at org.testcontainers.DockerClientFactory.client(DockerClientFactory.java:186)
	at org.testcontainers.DockerClientFactory$1.getDockerClient(DockerClientFactory.java:104)
	at com.github.dockerjava.api.DockerClientDelegate.authConfig(DockerClientDelegate.java:108)
	at org.testcontainers.containers.GenericContainer.start(GenericContainer.java:321)

Is there additional logging I could turn on, or would anyone have suggestions as to what to look at?

[eddumelendez]

For logs, have you check https://www.testcontainers.org/supported_docker_environment/logging_config/ ?

[mpiggott]

For logs, have you check https://www.testcontainers.org/supported_docker_environment/logging_config/ ?

I hadn't seen it, but it doesn't appear to have additional suggestions beyond the debug logging I enabled aside from tc which doesn't seem relevant.

[mpiggott]

I eventually tracked this down.

Locally testcontainers is able to use one of the hardcoded docker strategies. However on Jenkins these strategies don't work and in my OSGi environment the Thread's context class loader is set to a PaxExam ClassLoader. This ClassLoader does not have access to the classes in TestContainers, so all of the dynamic strategies fail.

To solve this we do something like this:

GenericContainer gc = ....;
ClassLoader cl = Thread.getCurrentThread().getContextClassLoader();
try {
  Thread.getCurrentThread().setContextClassLoader(GenericContainer.class.getClassLoader());
  gc.start();
}
finally {
  Thread.getCurrentThread().setContextClassLoader(cl);
}

Not really clear to me what motivates the usage of the Thread's context classloader here. It would also be helpful if the stacktraces were logged rather than swallowed.

[mpiggott]

For us we may need to create a subclass of GenericContainer to wrap this logic into start() but obviously that would prevent us from using the other concrete subtypes.