Enable quarkus:build outcome cache for the main integration test

[aloubyansky]

With the Gradle Enterprise caching enabled and this change the outcome of quarkus:build of the main integration test module will be cached after the third build.

FYI @jprinet

[jprinet]

Nice @aloubyansky 👍
Could we also check in .quarkus/quarkus-prod-config-dump to maximize cache hit rate?

[gsmet]

I'm not sure I understand why "after the third build"?

[jprinet]

I'm not sure I understand why "after the third build"?

The caching extension requires the dump configuration file to be created (happens when quarkus.config-tracking.enabled is enabled) in order to make the build goal cacheable.

With the current implementation, you need

• a first build to create the dump configuration file
• a second build to upload the cache entry to the cache node

Thus only the third build would get a cache hit.

This is why I asked to check in the dump configuration file to allow caching from the very first build

[jprinet]

Following up @maxandersen's suggestion to not check in .quarkus/quarkus-prod-config-dump, the GitHub workflow can be modified to cache the file (the path to .quarkus should be updated)

Could you update the PR accordingly, @aloubyansky ?

      - name: Cache Quarkus metadata
        uses: actions/cache@v3
        with:
          path: '.quarkus'
          key: ${{ runner.os }}-quarkus-metadata

[aloubyansky]

Ok, I added that adjustment, please review @jprinet and @gsmet. Thanks!

[jprinet]

Ok, I added that adjustment, please review @jprinet and @gsmet. Thanks!

LGTM 👍

[quarkus-bot]

Failing Jobs - Building fa84f2e

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✔️	JVM Tests - JDK 11					🔍
✖	JVM Tests - JDK 17	Build	Failures	Logs	Raw logs	🔍
✔️	JVM Tests - JDK 21					🔍

Full information is available in the Build summary check run.
You can also consult the Develocity build scans.

Failures

⚙️ JVM Tests - JDK 17 #

- Failing: integration-tests/opentelemetry-scheduler 

📦 integration-tests/opentelemetry-scheduler

✖ io.quarkus.it.opentelemetry.scheduler.OpenTelemetrySchedulerTest.schedulerSpanTest line 31 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with io.quarkus.it.opentelemetry.scheduler.OpenTelemetrySchedulerTest was not fulfilled within 1 seconds.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[gsmet]

Closing as I incorporated the changes into #37622 .