ElasticSearch Dev Service image cannot be replaced with custom-built image

[PeterGrzeschik]

Describe the bug

In the ElasticSearch DEV service you can use your own image (quarkus.elasticsearch.devservices.image-name), however it is not accepted because it is not name-compatible with the expected value: docker.elastic.co/elasticsearch/elasticsearch.

Expected behavior

Any image that extends an ElasticSearch image is accepted and used.

Actual behavior

ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
        [error]: Build step io.quarkus.elasticsearch.restclient.common.deployment.DevServicesElasticsearchProcessor#startElasticsearchDevService threw an exception: java.lang.RuntimeException: java.lang.IllegalStateException: Failed to verify that image 'registry.gitlab.com/xxxxx/search-service/elastic-with-files:my-tag' is a compatible substitute for 'docker.elastic.co/elasticsearch/elasticsearch'. This generally means that you are trying to use an image that Testcontainers has not been designed to use. If this is deliberate, and if you are confident that the image is compatible, you should declare compatibility in code using the `asCompatibleSubstituteFor` method. For example:
   DockerImageName myImage = DockerImageName.parse("registry.gitlab.com/xxxxx/search-service/elastic-with-files:my-tag").asCompatibleSubstituteFor("docker.elastic.co/elasticsearch/elasticsearch");
and then use `myImage` instead.
        at io.quarkus.elasticsearch.restclient.common.deployment.DevServicesElasticsearchProcessor.startElasticsearchDevService(DevServicesElasticsearchProcessor.java:98)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:977)
        at io.quarkus.builder.BuildContext.run(BuildContext.java:281)
        at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
        at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
        at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
        at java.base/java.lang.Thread.run(Thread.java:833)
        at org.jboss.threads.JBossThread.run(JBossThread.java:501)
Caused by: java.lang.IllegalStateException: Failed to verify that image 'registry.gitlab.com/xxxxx/search-service/elastic-with-files:my-tag' is a compatible substitute for 'docker.elastic.co/elasticsearch/elasticsearch'. This generally means that you are trying to use an image that Testcontainers has not been designed to use. If this is deliberate, and if you are confident that the image is compatible, you should declare compatibility in code using the `asCompatibleSubstituteFor` method. For example:
   DockerImageName myImage = DockerImageName.parse("registry.gitlab.com/xxxxx/search-service/elastic-with-files:my-tag").asCompatibleSubstituteFor("docker.elastic.co/elasticsearch/elasticsearch");
and then use `myImage` instead.
        at org.testcontainers.utility.DockerImageName.assertCompatibleWith(DockerImageName.java:270)
        at org.testcontainers.elasticsearch.ElasticsearchContainer.<init>(ElasticsearchContainer.java:95)
        at io.quarkus.elasticsearch.restclient.common.deployment.DevServicesElasticsearchProcessor.lambda$startElasticsearch$1(DevServicesElasticsearchProcessor.java:198)
        at java.base/java.util.Optional.orElseGet(Optional.java:364)
        at io.quarkus.elasticsearch.restclient.common.deployment.DevServicesElasticsearchProcessor.startElasticsearch(DevServicesElasticsearchProcessor.java:224)
        at io.quarkus.elasticsearch.restclient.common.deployment.DevServicesElasticsearchProcessor.startElasticsearchDevService(DevServicesElasticsearchProcessor.java:88)
        ... 11 more

How to Reproduce?

mvn io.quarkus.platform:quarkus-maven-plugin:2.12.1.Final:create
-DprojectGroupId=org.acme
-DprojectArtifactId=elasticsearch-quickstart
-DclassName="org.acme.datasource.GreetingResource"
-Dextensions="resteasy,resteasy-jackson,elasticsearch-rest-client"

cd elasticsearch-quickstart/

echo "quarkus.elasticsearch.devservices.image-name = debian:buster" >> ./src/main/resources/application.properties

mvn verify

Output of uname -a or ver

Linux ****** 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "17.0.3" 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.12.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) Maven home: /opt/maven Java version: 17.0.3, vendor: Private Build, runtime: /usr/lib/jvm/java-17-openjdk-amd64 Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "5.4.72-microsoft-standard-wsl2", arch: "amd64", family: "unix"

Additional information

This bug has the identical problem as: #20945

[quarkus-bot]

/cc @gsmet, @loicmathieu, @yrodiere

[languitar]

Is there a chance to make the solution from #20945 the default behavior for all dev services? If the user exchanges the image, he or she probably know why. Would be unfortunate if someone has to stumble upon this problem for each (new) dev service first.

[geoand]

Seems like an oversight. Would you like to provide a fix?

[gsmet]

@languitar yes, we should consider the user knows what they're doing. So if you feel like it, you can generalize this solution to all dev services. And let us know if you're not interested as it's probably something we should prioritize for 2.13.

Thanks!