In the current implementation, to benefit from an agent collecting data from JVM IT runs, the build flow is not straightforward. Basically, it's
./mvnw verify -DskipITs=false -Dquarkus.test.integration-test-profile=test-with-native-agent
// inspect, adjust your native configuration based on the output
./mvnw verify -Dnative
As long as there is a "manual" inspection of the native configuration after the first command, it doesn't look that bad.
However, a proper integration of the agent into the build should probably imply making it all work with a single Maven command. To achieve that Quarkus JVM and native build and test goals should be properly ordered and bound to the corresponding Maven build lifecycle phases.
What we would be looking for in this case is something like:
generate-code
compile
generate-code-test
test-compile
test: unit tests and QuarkusTest
package: JVM quarkus:build
integration-test: JVM integration tests
native image quarkus:build
native image integration tests
If we were to do something like this with the current default POM config, we would need to adjust the native profile like
There are a few issues with this profile (and current impl):
it appears with the current impl simply calling a profile native will be enough to do a native build, quarkus.native.enabled can be removed, we should fix that. That's why I called this one newNative.
quarkus-native-build is bound to post-integration-test and only for this execution we want to enable quarkus.native.enabled (not as a global project property). We should probably consider a dedicated Mojo parameter for it. systemProperties works as a PoC but it's not a proper way to configure this.
quarkus-native-integration-tests actually don't run with this config, since the failsafe-plugin has already run integration tests for the JVM and it considers it's a duplicate run.
[INFO] --- failsafe:3.2.5:integration-test (quarkus-native-integration-tests) @ test-app ---
[INFO] Skipping execution of surefire because it has already been run for this configuration
Description
In the current implementation, to benefit from an agent collecting data from JVM IT runs, the build flow is not straightforward. Basically, it's
As long as there is a "manual" inspection of the native configuration after the first command, it doesn't look that bad.
However, a proper integration of the agent into the build should probably imply making it all work with a single Maven command. To achieve that Quarkus JVM and native build and test goals should be properly ordered and bound to the corresponding Maven build lifecycle phases.
What we would be looking for in this case is something like:
QuarkusTest
If we were to do something like this with the current default POM config, we would need to adjust the
native
profile likeThere are a few issues with this profile (and current impl):
native
will be enough to do a native build,quarkus.native.enabled
can be removed, we should fix that. That's why I called this onenewNative
.quarkus-native-build
is bound topost-integration-test
and only for this execution we want to enablequarkus.native.enabled
(not as a global project property). We should probably consider a dedicated Mojo parameter for it.systemProperties
works as a PoC but it's not a proper way to configure this.quarkus-native-integration-tests
actually don't run with this config, since the failsafe-plugin has already run integration tests for the JVM and it considers it's a duplicate run.We could probably find a way to still run them.
FYI @galderz
Implementation ideas
No response