[Bug]: library/mysql is not a valid substitute for mysql

Module

MySQL

Testcontainers version

1.17.3

Using the latest Testcontainers version?

Yes

Host OS

Linux

Host Arch

x86

Docker version

Client:
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.18.3
 Git commit:        100c70180f
 Built:             Sat Jun 11 23:27:28 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.18.3
  Git commit:       a89b84221c
  Built:            Sat Jun 11 23:27:14 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.6.6
  GitCommit:        10c12954828e7c7c9b6e0ea9b0c02b01407d3ae1.m
 runc:
  Version:          1.1.3
  GitCommit:        
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

We are using new MySQLContainer<>("mysql:8.0.16") to create a mysql container locally. All is working fine.

However, in our CI we now introduced a Docker proxy via Nexus. Since we don’t want to use the proxy locally, but only in the CI, we integrated it via an environment variable TESTCONTAINERS_HUB_IMAGE_NAME_PREFIX: "registry-proxy.awesomecorp.eu/".

This did not work, as Nexus internally stores the mysql image not as mysql, but library/mysql (which is the same, e.g. you can do docker pull library/mysql:latest on your machine right now, and it will work). So we adjusted the code to: new MySQLContainer<>("library/mysql:8.0.16"). But now the test fails at startup with Failed to verify that image 'library/mysql:8.0.16' is a compatible substitute for 'mysql'.. It provides the asCompatibleSubstituteFor method for a fix, and that works. However, I would argue it should not be necessary, as its essentially the same image.

Alas, DockerImageName.parse("mysql:8.0.16").equal(DockerImageName.parse("library/mysql:8.0.16")) should be true.

Relevant log output

No response

Additional Information

No response

[kiview]

All good, I think you have a point here. We just need to ponder if such a change will have other unintended sideffects and particularly, how well it will play with other Docker-API compatible container engines, that are not Docker (thinking of podman here).

[kiview]

I am not opposed to it in general, but I feel that instead of sprinkling the code with making docker.io prefixed image names, we need more of an architectural solution to the codebase as a whole, especially since it also relates to https://github.com/testcontainers/testcontainers-java/issues/5275.

As you can see in this issue, besides the docker.io default registry topic, there is also the implicit behavior regarding the library/ prefixing for Docker Hub images.