QuarkusIntegrationTest: Access to DevServices after #18933

[bdevreugd-vialis]

Description

Issue #18854 allowed access to the dev service urls inside integration tests.
However, issue #18933 causes dev services to be started inside a shared network which will return urls inside that network. The integration test however is run from the host, which has no access to that shared network.

Could you add a method for integration tests, to acces the dev services?

Implementation ideas

Expose a property with postfix .from-host that will contain the original URL (with the mapped port)?

[quarkus-bot]

/cc @geoand, @stuartwdouglas

[geoand]

Thanks for reporting!

[geoand]

I'll try and take a look next week

[Koekebakkert]

Any progress on this? It worked in 2.1.0.CR1 and Final only. It is still broken in 2.4.1.Final. Desperately needed.

[geoand]

What is your exact use case?

[Koekebakkert]

Thanks for your quick response.

I am using a WireMockServer inside an implementation of QuarkusTestResourceLifecycleManager to stub a graphql service.

During integration test phase on Linux using the application image, the application gets lauched as:

docker run --rm -p 9990:9990 -p 8444:8444 --env QUARKUS_HTTP_PORT=9990 --env QUARKUS_HTTP_SSL_PORT=8444 --env TEST_URL=http://0.0.0.0:9990 --env GRAPHQL_SERVICE_MP_GRAPHQL_URL=http://localhost:8080/graphql application:1.0.1-SNAPSHOT

and the application cannot reach localhost:8080

Everything will run fine with the '--network host' option, but that won't work on windows apparently.

With Quarkus 2.1.0.Final the application integration-test was working, it launched as:

docker, run, --rm, --net=host, --env, QUARKUS_HTTP_PORT=9990, --env, QUARKUS_HTTP_SSL_PORT=8444, --env, TEST_URL=http://0.0.0.0:9990, --env, GRAPHQL_SERVICE_MP_GRAPHQL_URL=http://localhost:8080/graphql, application:1.0.1-SNAPSHOT

Since 2.2.0.Final and up to 2.4.1.Final it is broken.

How to proceed?

[geoand]

This should be taken care of in 2.5.0.CR1 (likely to be released in a few days) via #21316.

Essentially what that PR brings is the ability to know the network the application container (by implementing DevServicesContext.ContextAware in your implementation of QuarkusTestResourceLifecycleManager) will be launched on, thus giving you the ability to launch your service on the same network.

[Koekebakkert]

Looking forward to 2.5.0 ;)

[geoand]

If all goes well, 2.5.0.CR1 will be out today :)

[Koekebakkert]

Unfortunately, it still does not work with 2.5.0.Final.

I have tried it on both openSUSE Tumbleweed and LEAP where 2.1.0.Final works great.

What can I do to help troubleshoot the issue?

[geoand]

What does your code look like? What containers are launched when you start the test?

[Koekebakkert]

I have created a small project that can be used to hammer out the integration test issue. It will succeed with 2.1.0.Final but will fail with a higher version, including 2.5.0.Final. Where do I put it?

[geoand]

Just upload it to Github

[Koekebakkert]

Well here it is: https://github.com/Koekebakkert/quarkus-wiremockserver-integration-test-service

Feel free to ask any question ;)

[geoand]

Thanks, I'll try and have a look tomorrow

[geoand]

It seems from the project you uploaded that you have not updated the code according to #19080 (comment) nevermind, I see that you are not using testcontainers.

I need to think about how this can be addressed.

[geoand]

Actually there is no good way to support that use case if we want to support the more common case where a supporting container is launched. You'll probably have to switch from Wiremock to https://www.testcontainers.org/modules/mockserver/