CI - ITs not always executed - Sometimes only the parent module is built

[gsmet]

We recently split the ITs in a separate run in our JVM matrix. So that they can run in parallel of the main testing.

For a change to the BOM - an update to SmallRye Config, we have an issue: only the parent integration-tests/ module is built and the children are not.

See: https://github.com/quarkusio/quarkus/actions/runs/13415076450/job/37474673050 - change is: https://github.com/quarkusio/quarkus/pull/46359/files

The initial GIB run perfectly sees that the ITs should be run but somehow when actually executing the ITs, it doesn't. I'm wondering if not having the module in which the change was made could be a problem for GIB or if the fact we pass the modules as -f integration-tests -pl!exclusion1... is being problematic?

In the IT run itself, GIB says:

[INFO] No changed artifacts detected: Executing validate goal on current project only, skipping all submodules.
[INFO] gitflow-incremental-builder exiting...

@famod I would appreciate some help to figure out what we should do to fix it.

See:

quarkus/.github/workflows/ci-actions-incremental.yml

Line 59 in 4ec24b1

JVM_TEST_INTEGRATION_TESTS_SELECTOR: "-f integration-tests -pl !gradle -pl !maven -pl !devmode -pl !devtools"

and:

quarkus/.github/workflows/ci-actions-incremental.yml

Lines 441 to 448 in 4ec24b1

	run: |
	if [[ "${{ matrix.java.category }}" == *"Integration"* ]]; then
	PL=$JVM_TEST_INTEGRATION_TESTS_SELECTOR
	else
	PL=$JVM_TEST_NORMAL_TESTS_SELECTOR
	fi
	# Despite the pre-calculated run_jvm flag, GIB has to be re-run here to figure out the exact submodules to build.
	./mvnw $COMMON_MAVEN_ARGS $COMMON_TEST_MAVEN_ARGS $PTS_MAVEN_ARGS $PL clean install -Dsurefire.timeout=1200 -Dno-test-kubernetes ${{ matrix.java.maven_args }} ${{ needs.build-jdk17.outputs.gib_args }}

[holly-cummins]

The problem only seems to happen when gib would like to build a subset of the modules. If gib generates an empty GIB_IMPACTED set, the integration tests run normally.

[holly-cummins]

I did an experiment to see if -Dgib.disableSelectedProjectsHandling helped, and ... it did not. Which isn't too surprising, based on the docs, but the docs also say -f should work fine, so ...

[holly-cummins]

I did another experiment, to see if cd into the directory we want to change both change the relative path root, and I suspect a mismatch in where relative paths come from in the gib set and what the pom sees is maybe the problem.

That is, gib may be wanting to match integration-tests/openapi, but the pom would think of that submodule as openapi. I saw something similar when I had to strip integration-tests/ from the -pl arguments I passed to mvn when i also had a -f flag.

[famod]

FTR, I received then ping but I won't be able to look into this issue before late sunday evening.

[gsmet]

@famod FWIW, I worked on something to inject the list of modules directly in the matrix instead of rerunning GIB again in the JVM case. I think it's probably a good idea going forward. It's on top of my work on RunsOn though but I can create a draft PR.

[gsmet]

@famod I created #46421 (will see how CI reacts)

[famod]

I can reproduce this behavior locally by changing the BOM an running:

./mvnw validate -Pincremental -Dgib.rb=upstream/main -f integration-tests

Adding -X reveals:

[DEBUG] Ignoring changed file in non-reactor module: /home/famod/proj/quarkus/bom/application/pom.xml

The docs could certainly do a better job in hinting at that pitfall, but it's just the way it has always worked (or hasn't).
Note that this message was demoted from WARNING to DEBUG back in 2022/4.2.0: gitflow-incremental-builder/gitflow-incremental-builder#567

So, GIB needs the full reactor but Maven is trimming it down when using -f.

Btw, this is not specific to BOM changes; same happens when touching e.g. build-parent/pom.xml.

I'll have a look at #46421 tomorrow or so.

[holly-cummins]

I've raised gitflow-incremental-builder/gitflow-incremental-builder#1003 to track this, since @gsmet has done a workaround for the Quarkus issue. It's got completely wrong content in it since I hadn't spotted your comment, @famod! I'll go revise.