Digest pinning for microcks-uber-async-minion image

[rquinio1A]

Describe the bug

When trying to use a fixed digest for the microcks-uber-async-minion image via:

quarkus.microcks.devservices.ensemble.async-image-name=quay.io/microcks/microcks-uber-async-minion:1.9.0@sha256:7bf022a341435c5f7c1a9e764e660390de0a2c49578a1763923e2202d0f76fff

I get:

Caused by: java.lang.IllegalStateException: Failed to verify that image 'quay.io/microcks/microcks-uber-async-minion:1.9.0@sha256:7bf022a341435c5f7c1a9e764e660390de0a2c49578a1763923e2202d0f76fff' is a compatible substitute for 'quay.io/microcks/microcks-uber-async-minion'. 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("quay.io/microcks/microcks-uber-async-minion:1.9.0@sha256:7bf022a341435c5f7c1a9e764e660390de0a2c49578a1763923e2202d0f76fff").asCompatibleSubstituteFor("quay.io/microcks/microcks-uber-async-minion");
and then use `myImage` instead.
        at org.testcontainers.utility.DockerImageName.assertCompatibleWith(DockerImageName.java:279)
        at io.github.microcks.testcontainers.MicrocksAsyncMinionContainer.<init>(MicrocksAsyncMinionContainer.java:81)
        at io.github.microcks.quarkus.deployment.DevServicesMicrocksProcessor.completeMicrocksEnsemble(DevServicesMicrocksProcessor.java:275)

This is pointing to the same multi-arch manifest digest as when using the latest tag:

quarkus.microcks.devservices.ensemble.async-image-name=quay.io/microcks/microcks-uber-async-minion:latest

Note that digest pinning works fine on quarkus.microcks.devservices.image-name !

Btw it might be risky for quarkus-microcks default config values to point to 'latest' ? In case there's a breaking on microcks APIs, all previous versions of the extension will fail. It might be safer to point to a tag, though it means releasing a new version of the extension when there's a new minor of microcks... In my case I also need to configure the registry name of the images to go through an internal registry.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

mvn quarkus:dev

Microcks version or git rev

0.2.4

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

quarkus:dev

Additional information

podman 4.9.1 running on Windows + WSL.

[lbroudoux]

Thanks for opening this one. I succeeded in reproducing it. We may have a compatibility declaration for main container image that has not bee applied to async minion too... Checking this.

[lbroudoux]

This was the right guess ;-) This has also to be fixed for the postman-runtime container image name.