Change ArtifactLauncher.start to return the listening address

[radcortez]

Calling ArtifactLauncher.start to start Quarkus now returns an Optional<ListeningAddress>, which was already available when starting the process internally. The ListeningAddress is then registered with the test Context, which allows us to avoid using System properties to propagate the running port.

This also means that it removes the ability to query quarkus.http.port and quarkus.http.test-port from the test itself using Config to get the real port (in case of using a random port for integration tests). From our tests, I don't see us doing that, but that doesn't mean users out there aren't. We could probably add a JUnit ParameterResolver to support injection of the ListeningAddress, but I'm not sure if this would be the final API we want to expose, since I think it would be interesting to have a unified API for both test and regular runtime. The real port is still registered with RESTAssured, so that is a way to get it if required. Again, this only applies to tests running outside Quarkus.

Also, io.quarkus.test.junit.QuarkusTestProfile#getConfigOverrides, which was being set in SystemProperties, was moved to set the properties directly into the runner arguments, and set directly into the CuratedApplication when we require DevServices. This also means that properties set by io.quarkus.test.junit.QuarkusTestProfile#getConfigOverrides can no longer be retrieved by ConfigProvider.getConfig in integration-tests. Unsure if this is something that users use, but I'm thinking that we need to ban the usage of ConfigProvider.getConfig, and offer it as a test parameter, so we can create local instances to each test.

If this becomes a big issue, we can temporarily register the ports with System properties again. Hopefully, it shouldn't be required if we can do all the related work in a single release. This relates to:

• API to store real Runtime values #51209
• Mechanism to register Runtime Information which depends on Configuration #46915

Splitting this into smaller PRs to make it easier to review and track.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 7922fa3.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ Maven Tests - JDK 21 Semeru

📦 integration-tests/maven

❌ io.quarkus.maven.it.CreateProjectMojoIT.generateNewProjectAndRun - History

• Condition io.quarkus.test.devmode.util.DevModeClient$$Lambda/0x00000000a2a9bd90 was not fulfilled within 3 minutes. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Condition io.quarkus.test.devmode.util.DevModeClient$$Lambda/0x00000000a2a9bd90 was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1129)
	at io.quarkus.test.devmode.util.DevModeClient.getHttpResponse(DevModeClient.java:97)
	at io.quarkus.test.devmode.util.DevModeClient.getHttpResponse(DevModeClient.java:88)

❌ io.quarkus.maven.it.CreateProjectMojoIT.generateNewProjectAndRun - History

• Condition io.quarkus.test.devmode.util.DevModeClient$$Lambda/0x00000000a2a9bd90 was not fulfilled within 3 minutes. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Condition io.quarkus.test.devmode.util.DevModeClient$$Lambda/0x00000000a2a9bd90 was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1160)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1129)
	at io.quarkus.test.devmode.util.DevModeClient.getHttpResponse(DevModeClient.java:97)
	at io.quarkus.test.devmode.util.DevModeClient.getHttpResponse(DevModeClient.java:88)

---

⚙️ MicroProfile TCKs Tests

📦 tcks/microprofile-lra

❌ org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable - History

• Expecting the metric Compensated callback was called Expected: a value equal to or greater than <1> but: <0> was less than <1> - java.lang.AssertionError

java.lang.AssertionError: 
Expecting the metric Compensated callback was called
Expected: a value equal to or greater than <1>
     but: <0> was less than <1>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.eclipse.microprofile.lra.tck.TckRecoveryTests.assertMetricCallbackCalled(TckRecoveryTests.java:210)
	at org.eclipse.microprofile.lra.tck.TckRecoveryTests.testCancelWhenParticipantIsUnavailable(TckRecoveryTests.java:195)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)