Fix for Integration Tests with test profiles: dev services config overrides

[ozangunalp]

QuarkusIntegrationTest and QuarkusMainIntegrationTest prepare dev services after determining the test profile and applying config overrides (using system properties).

Added QuarkusIntegrationTest to redis-devservices IT module and enabled integration test execution.

• Resolves: Integration tests cannot use fixed port for dev services #48615

[ozangunalp]

Rebasing after #48614

[ozangunalp]

@alesj @brunobat The failure in integration-tests/observability-lgtm LgtmResourcesIT is related.
I can't understand what it is supposed to test.

For context, before getConfigOverrides in a profile were passed to the application, but NOT to the augmentation step to start dev services.

With this change config overrides are also "active" on custom augmentation to start dev services.

[ozangunalp]

Failing opentelemetry tests are flaky, and I cannot reproduce the failing VertxVirtualThreadTest locally. I don't expect that they are related.

For the LgtmResourceIT I think we need to remove that test. Dev resources can't work with QuarkusIntegrationTest s because they rely on a custom runtime config source to create services at first config get (or property names get).

It did seemed like working before because the profile config wasn't read. So observability dev service was active, not the dev resource mechanism.

[holly-cummins]

Failing opentelemetry tests are flaky, and I cannot reproduce the failing VertxVirtualThreadTest locally. I don't expect that they are related.

I agree.

For the LgtmResourceIT I think we need to remove that test. Dev resources can't work with QuarkusIntegrationTest s because they rely on a custom runtime config source to create services at first config get (or property names get).

It did seemed like working before because the profile config wasn't read. So observability dev service was active, not the dev resource mechanism.

Ohhh, that's so subtle! I wonder how often that happens. Often, I suspect. I had to work quite hard in the dev service tests to check the test was connected to the right one, and normal tests wouldn't necessarily do that. That might explain why this test is known to be flaky, though.

[ozangunalp]

I wonder how often that happens.

This is only for LGTM Dev Resource, as it is the only dev resource implementation we've.

[brunobat]

I'll let @alesj comment on this.

[holly-cummins]

I think we can remove these two comments, right?

[holly-cummins]

I'd like to see a more generic solution for this, so that we have consistent behaviour in integration tests rather than per-project adjustments to try and ensure integration tests run. But we may not be able to achieve that.

[holly-cummins]

Confirmed that this isn't the right way to get integration tests running; we only want them to run in native CIs. I've fixed and updated the native matrix instead.