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
Just gave 1.14.0 a spin to see if it fixes my issue with Dockerfiles requiring base images hosted in a private registry.
Unfortunately this is still not working.
What I saw from debugging a little:
It seems like the new logic is trying to pull too early,
protectedfinalStringresolve() {
Loggerlogger = DockerLoggerFactory.getLogger(dockerImageName);
DockerClientdockerClient = DockerClientFactory.instance().client();
dependencyImageNames.forEach(imageName -> {
try {
log.info("Pre-emptively checking local images for '{}', referenced via a Dockerfile. If not available, it will be pulled.", imageName);
DockerClientFactory.instance().checkAndPullImage(dockerClient, imageName);
} catch (Exceptione) {
log.warn("Unable to pre-fetch an image ({}) depended upon by Dockerfile - image build will continue but may fail. Exception message was: {}", imageName, e.getMessage());
}
});
[... ommittedforbrevity]
BuildImageCmdbuildImageCmd = dockerClient.buildImageCmd(in);
configure(buildImageCmd);
[...]
}
notice how dependencyImageNames is iterated before the call to configure while configure is the method that will actually populate dependencyImageNames.
So running my tests after docker system prune -a still results in failure .
What I also noticed is that org.testcontainers.containers.GenericContainer#logger will trigger a build of the image in question.
This prevents using .withStartupAttempts(2) as a workaround
The text was updated successfully, but these errors were encountered:
a.) GitHub notifications in Slack FTW :D
b.) we identified a few more issues and will release 1.14.1 later this week to address them, including that PR. Sorry!
Hey,
Just gave 1.14.0 a spin to see if it fixes my issue with Dockerfiles requiring base images hosted in a private registry.
Unfortunately this is still not working.
What I saw from debugging a little:
It seems like the new logic is trying to pull too early,
notice how
dependencyImageNames
is iterated before the call toconfigure
while configure is the method that will actually populatedependencyImageNames
.So running my tests after
docker system prune -a
still results in failure .What I also noticed is that
org.testcontainers.containers.GenericContainer#logger
will trigger a build of the image in question.This prevents using
.withStartupAttempts(2)
as a workaroundThe text was updated successfully, but these errors were encountered: