Native Image Build - Reuse-Existing requires docker runtime

[Diom]

Describe the bug

I am attempting to develop a two part Quarkus CI Pipeline in Jenkins. The process is to build the core artifact and then run the image build and push per target registry. So:

1. Build Artifact with Tests and Reports (docker agent)
2. Build the image (node agent with docker install)
3. Push to Reg1 (docker agent)
4. Push to Reg2 (docker agent)

This works fine for JVM builds but fails for Native Images.

During Stage 2 I build the native executable when a 'Native' parameter is set. For Stages 3 & 4, I use a command like so:

mvn package $MVN_OPTS -DskipTests -Dquarkus.container-image.build=true \
    -Dquarkus.container-image.builder=jib \
    -Dquarkus.container-image.push=true \
    -Dquarkus.container-image.tag=$tag \
    -Dquarkus.container-image.registry=$registry \
    -Dquarkus.native.reuse-existing=true -Pnative

Expected behavior

I expect that the JIB builder will construct the image, set the correct entrypoint and push the image to registry without requiring an intermediate container-runtime

Actual behavior

The build fails

17:26:32  Caused by: java.lang.IllegalStateException: No container runtime was found to run the native image builder. Make sure you have Docker or Podman installed in your environment.
17:26:32      at io.quarkus.deployment.pkg.steps.NativeImageBuildContainerRunner.detectContainerRuntime (NativeImageBuildContainerRunner.java:151)
17:26:32      at java.util.Optional.orElseGet (Optional.java:369)
17:26:32      at io.quarkus.deployment.pkg.steps.NativeImageBuildContainerRunner.<init> (NativeImageBuildContainerRunner.java:33)
17:26:32      at io.quarkus.deployment.pkg.steps.NativeImageBuildLocalContainerRunner.<init> (NativeImageBuildLocalContainerRunner.java:19)
17:26:32      at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.getNativeImageBuildRunner (NativeImageBuildStep.java:291)
17:26:32      at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build (NativeImageBuildStep.java:177)
17:26:32      at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
17:26:32      at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
17:26:32      at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
17:26:32      at java.lang.reflect.Method.invoke (Method.java:566)
17:26:32      at io.quarkus.deployment.ExtensionLoader$2.execute (ExtensionLoader.java:887)
17:26:32      at io.quarkus.builder.BuildContext.run (BuildContext.java:277)
17:26:32      at org.jboss.threads.ContextHandler$1.runWith (ContextHandler.java:18)
17:26:32      at org.jboss.threads.EnhancedQueueExecutor$Task.run (EnhancedQueueExecutor.java:2449)
17:26:32      at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run (EnhancedQueueExecutor.java:1478)
17:26:32      at java.lang.Thread.run (Thread.java:829)
17:26:32      at org.jboss.threads.JBossThread.run (JBossThread.java:501)

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

Java version: 11.0.16, vendor: Oracle Corporation, runtime: /usr/local/openjdk-11

GraalVM version (if different from Java)

Container Build

Quarkus version or git rev

2.6.3.Final

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

maven:3.8.6

Additional information

No response

[quarkus-bot]

/cc @geoand

[geoand]

This isn't Jib that is failing, it's the native image generation, which is attempting to build the native binary using docker or podman because GraalVM is not installed locally

[Diom]

@geoand Yes, but isn't that a problem given that the native executable already exists and the quarkus.native.reuse-existing flag has been set? With this set of parameters I would expect that:

1. The native artifact does not need to be created, so no GraalVM execution or Docker container is required
2. The JIB flag is set so no need for docker to build the image
   • It seems to support it given that there are native specific container-image options
3. quarkus.container-image.push (and registry) is set, so no need to push into the local docker daemon.

This is why I think that it is a bug

[geoand]

Actually, that's a very good point.