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

[Bug]: Unable to override Docker Image via testcontainers.properties when using ComposeContainer #9222

Open
apoorvg03 opened this issue Sep 13, 2024 · 5 comments

Comments

@apoorvg03
Copy link

Module

Core

Testcontainers version

1.20.1

Using the latest Testcontainers version?

Yes

Host OS

macOS

Host Arch

x86

Docker version

Client:
 Cloud integration: 1.0.17
 Version:           20.10.8
 API version:       1.41
 Go version:        go1.16.6
 Git commit:        3967b7d
 Built:             Fri Jul 30 19:55:20 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.8
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.16.6
  Git commit:       75249d8
  Built:            Fri Jul 30 19:52:10 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.9
  GitCommit:        e25210fe30a0a703442421b0f60afac609f950a3
 runc:
  Version:          1.0.1
  GitCommit:        v1.0.1-0-g4144b63
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

I am attempting to override the default Docker Image version used in ComposeContainer by specifying a custom image version via compose.container.image in testcontainers.properties. However, the override does not seem to take effect and the container still uses the default version which is 24.0.2.

testcontainers.properties file:

compose.container.image=docker:25.0.2

Relevant log output

08:16:41.871 [main] INFO tc.docker:24.0.2 -- Creating container for image: docker:24.0.2

Additional Information

No response

@fokion
Copy link
Contributor

fokion commented Sep 21, 2024

I can have a look if you want @eddumelendez

@fokion
Copy link
Contributor

fokion commented Sep 21, 2024

Based on an initial view I see the issue at ComposeContainer as the constructor creates a compose delegate based on the DEFAULT_IMAGE_NAME instead of checking if we have a property override.

public ComposeContainer(String identifier, List<File> composeFiles) {
        this.composeDelegate =
            new ComposeDelegate(
                ComposeDelegate.ComposeVersion.V2,
                composeFiles,
                identifier,
                COMPOSE_EXECUTABLE,
                DEFAULT_IMAGE_NAME
            );
        this.project = this.composeDelegate.getProject();
    }

@fokion
Copy link
Contributor

fokion commented Sep 21, 2024

@eddumelendez feel free to review on this one :)

@eddumelendez
Copy link
Member

eddumelendez commented Oct 17, 2024

Hi, the approach we would like to follow is

  • Add new constructors allowing for an image name
public ComposeContainer(DockerImageName image, File... composeFiles) {}

public ComposeContainer(DockerImageName image, List<File> composeFiles) {}

public ComposeContainer(DockerImageName image, String identifier, File... composeFiles) {}

public ComposeContainer(DockerImageName image, String identifier, List<File> composeFiles) {}
  • Log warning if withLocal(true) is used in conjunction with custom image name (since image would not be used)

  • Consider changes in DockerComposeContainer as well

This way the implementation aligns with other modules.

@fokion
Copy link
Contributor

fokion commented Oct 18, 2024

Do you want to assign it to me?

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

No branches or pull requests

3 participants