Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ImageFromDockerfile still fails if Dockerfile requires private base image #2575

Closed
JakobFels opened this issue Apr 14, 2020 · 4 comments
Closed
Labels
Milestone

Comments

@JakobFels
Copy link

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,

  protected final String resolve() {
        Logger logger = DockerLoggerFactory.getLogger(dockerImageName);

        DockerClient dockerClient = 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 (Exception e) {
                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());
            }
        });

           [... ommitted for brevity]

            BuildImageCmd buildImageCmd = 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

@bsideup
Copy link
Member

bsideup commented Apr 14, 2020

probably fixed by #2573?

@JakobFels
Copy link
Author

a.) wow you're fast
b.) yeah, that looks like it will solve my issue.

Thanks :)

@bsideup bsideup added this to the next milestone Apr 14, 2020
@bsideup
Copy link
Member

bsideup commented Apr 14, 2020

@JakobFels

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!

@JakobFels
Copy link
Author

Just saw that this is still open, 1.4.1 fixed my issue, thanks a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants