quarkus.native.container-build=true (GraalVM/Mandrel native-image used from a docker image during NativeImageBuildStep)
and quarkus.container-image.build=true (the application native executable is dockerized by JibProcessor)
it would be great if @NativeImageTest would be able to actually use that docker image to start the application, rather than trying to start the native executable inside/target from NativeImageBuildStep, because it may fail to start if incompatible with the host OS (i.e. building a Linux executable on a Windows laptop).
I don't know if it is technically feasible for container-image-* extensions to change the behavior of NativeImageTest, which is core.
NativeImageLauncher might use TestContainers to start the containerized native image if quarkus.container-image.build build=true, rather than trying to launch the xxx-runner native executable ?
It would look for the image built during package phase, retrieving it from the docker daemon or the docker registry (depending on value of quarkus.container-image.push).
Description
When using:
quarkus.native.container-build=true
(GraalVM/Mandrel native-image used from a docker image during NativeImageBuildStep)quarkus.container-image.build=true
(the application native executable is dockerized by JibProcessor)it would be great if
@NativeImageTest
would be able to actually use that docker image to start the application, rather than trying to start the native executable inside/target from NativeImageBuildStep, because it may fail to start if incompatible with the host OS (i.e. building a Linux executable on a Windows laptop).This is also somehow related to #8654
Implementation ideas
I don't know if it is technically feasible for container-image-* extensions to change the behavior of NativeImageTest, which is core. NativeImageLauncher might use TestContainers to start the containerized native image if
quarkus.container-image.build build=true
, rather than trying to launch the xxx-runner native executable ? It would look for the image built during package phase, retrieving it from the docker daemon or the docker registry (depending on value ofquarkus.container-image.push
).https://github.com/quarkusio/quarkus/issues/13818
$upstream:13818$