quarkusio / quarkus

Quarkus: Supersonic Subatomic Java.
https://quarkus.io
Apache License 2.0
13.73k stars 2.67k forks source link

Test containers create a new network per integration test when using different test resources per test #25441

Open taroquu opened 2 years ago

taroquu commented 2 years ago

Describe the bug

Within our project, we build our app as a docker image, and execute integration tests against it. It is mostly the case that each integration test has different test resources using @QuarkusTestResource. As such, each time a new integration test class is run by failsafe, a fresh docker container will be started - instead of reusing the same one.

Each time this happens, due to the way the class loading works, we will get a new org.testcontainers.containers.Network.SHARED instance for each test class, meaning that test containers creates a brand new docker network each time an integration test class is run.

We have a lot of integration test classes and the creation of a new network for each one is causing our bitbucket pipeline to reach some level of saturation and causes resolution of host names to start failing.

I have created a simple work around for our project by adding the test containers dependency to our POM and adding it to quarkus.class-loading.parent-first-artifacts

Expected behavior

Only one network is created by test containers for all integration tests - even if they all use different test resources.

Actual behavior

A new network is created for each integration test class that runs.

How to Reproduce?

I am afraid I cannot share our codebase with, but I have created a simple reference to demonstrate the problem which you can find here: https://bitbucket.org/mcassidy/quarkusdockernetworkissue/src/master/

If you have a look at the pipeline output for it, https://bitbucket.org/mcassidy/quarkusdockernetworkissue/addon/pipelines/home#!/results/5 you can see, that I have got 2 integration tests GreetingResourceIT and SecondGreetingResourceIT, each runs a docker run command to start the container and each passes a different --net argument each time. Whilst there are only 2 integration test classes in this example, so the saturation does not occur this does demonstrate the creation of a new network per test class. Given a sufficient volume of integration test classes too many networks will be created and the problem will occur.

Output of uname -a or ver

Darwin Martins-MBP 20.6.0 Darwin Kernel Version 20.6.0: Tue Feb 22 21:10:41 PST 2022; root:xnu-7195.141.26~1/RELEASE_X86_64 x86_64

Output of java -version

java version "13" 2019-09-17 Java(TM) SE Runtime Environment (build 13+33) Java HotSpot(TM) 64-Bit Server VM (build 13+33, mixed mode, sharing)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.8.3.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T16:06:16+01:00)

Additional information

No response

geoand commented 2 years ago

@famod didn't you also want to make testcontainers parent-first for some reason?

famod commented 2 years ago

@geoand yeah: https://github.com/testcontainers/testcontainers-java/issues/5284#issuecomment-1120184634

Just little to no time currently...

geoand commented 2 years ago

@famod thanks!

@taroquu mind opening a pull request making testcontainers parent first so we can see what CI says? I think it should work without issue

ejba commented 2 years ago

@geoand @famod is it just add the dependency in the runtime/pom.xml?

geoand commented 2 years ago

@ejba it's a matter of adding configuration to the quarkus-bootstrap-maven-plugin. See this for an example.

geoand commented 2 years ago

Reopening as we had to revert the parent first change