Improve a build flow of a native image with input from an agent collecting data from JVM IT runs

[aloubyansky]

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

./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

        <profile>
            <id>newNative</id>
            <activation>
                <property>
                    <name>newNative</name>
                </property>
            </activation>
            <properties>
                <skipITs>false</skipITs>
                <!-- quarkus.native.enabled>true</quarkus.native.enabled -->
            </properties>
            <build>
                <plugins>
                    <plugin>
                        <groupId>${quarkus.platform.group-id}</groupId>
                        <artifactId>quarkus-maven-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>quarkus-native-build</id>
                                <goals>
                                    <goal>build</goal>
                                </goals>
                                <phase>post-integration-test</phase>
                                <configuration>
                                    <systemProperties>
                                        <quarkus.native.enabled>true</quarkus.native.enabled>
                                    </systemProperties>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                    <plugin>
                        <artifactId>maven-failsafe-plugin</artifactId>
                        <executions>
                            <execution>
                                <id>quarkus-native-integration-tests</id>
                                <goals>
                                    <goal>integration-test</goal>
                                </goals>
                                <phase>post-integration-test</phase>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>

There are a few issues with this profile (and current impl):

1. 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.
2. 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.
3. 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

We could probably find a way to still run them.

FYI @galderz

Implementation ideas

No response

[quarkus-bot]

/cc @zakkak (native-image)