Testcontainers-java: Using DockerComposeContainer with a local image does not work

[aruizca]

Hi there,

I am just trying out TestContainers to launch a container with Atlassian Confluence inside which I know it works when using Dokcer for Mac the usual way.

My docker-compose.yml file looks like this:

version: "3"
services:
  confluence:
    image: confluence-4-testing
    volumes:
      - "docker-maven-repo:/root/.m2"
    ports:
      - "1990:1990"
    networks:
      - confluence-test-network
    environment:
      - CONFLUENCE_VERSION

networks:
  confluence-test-network:
    driver: bridge

volumes:
  docker-maven-repo:

please not the image which is a local one and it is not available in any docker hub.

My TestContainer is declared as per the following sentence:

    @Shared
    DockerComposeContainer compose = new DockerComposeContainer(new File("docker-compose.yml"))
            .withEnv("CONFLUENCE_VERSION", "6.8.2")
            .withExposedService("confluence_1",1990)
            .withLocalCompose(true)
            .waitingFor("confluence_1", Wait.forListeningPort())

and the error I am getting is:

org.testcontainers.containers.ContainerLaunchException: Local Docker Compose exited abnormally with code 1 whilst running command: pull

IMO it should not be pulling the image remotely. As I said this work just running docker-compose run --rm --service-ports -e CONFLUENCE_VERSION=6.8.2 confluence

Thanks for your help!

[rnorth]

IMO it should not be pulling the image remotely

I think you're right - we did this originally so that pull failures would be made visible more quickly, but it breaks when you have local-only images.

We should just think about repeatability, though: the tests become dependent upon the local image being present and consistently built beforehand. I'm sure you understand this and have your build process set up to deal with it, but we prefer to at least gently nudge Testcontainers users towards doing things in as repeatable a way as possible.

So: Maybe instead of removing the pull step (which was my first instinct) we could allow it to fail, log a warning, and proceed to do run. The warning message would be something along the lines of docker-compose could not pull all required images - local images will be used instead.

WDYT?

[kiview]

Another approach, which follows your argument for having a local image is a pretty conscious decision, would be to add a pull(false) builder flag.

I'm also happy with the warning, but am wondering, if this additional flag make things cleaner (or the API more confusing?).

[bsideup]

Warning sounds good to me 👍

[aruizca]

Warning seems fair enough. IMO this should be transparent for the developer, therefore no need to reflect the possibility of using local images in the API. Better make it and implicit option.

[Cuneytt]

started using testcontainers and hit this bug right away, is there a possible ETA on this, thanks

[alexanderkjall]

Another opinion: I have been working on building some docker images to use in testing of my project, and the extra network traffic from uploading the image and then downloading it again adds significantly to the turn around of my workflow.

[kiview]

@Cuneytt
I will look into it this week.