All devservices belonging to all TestProfiles are started at tests initialisation at startup

[dcdh]

Describe the bug

The bug is regarding devservice lifecycle when running tests having multiple test profiles.

When starting all tests using N TestProfile all containers will be started N times at startup.

Let say an application have 5 test profiles with a Postgres devservice, running all tests will produces at startup 10 containers : 5 ruyk and 5 Postgres.

In my scenario I do not reuse container.

Expected behavior

It should be likes it was before 3.22

Before the version 3.22 only one Postgres container will be used at once (and one ryuk will be created each time a test profile is started). At the end of the tests we will have 5 ruyk containers and only one last Postgres.

Actual behavior

When I start all tests I will have a lot of containers belonging to each test profile.

How to Reproduce?

My reproducer is a rest greeting application with a dependency to quarkus-jdbc-postgresql with two tests: one without testprofile and one with a testprofile.

1. git clone https://github.com/dcdh/code-with-quarkus-sample-testprofile.git (it uses quarkus version 3.22.1)
2. execute "mvn clean install"
3. You will obtains this

4. The tests will be executed after all four containers creation
5. Previous behavior change the version from 3.22.1 to 3.21.4 in the pom.xml
6. relaunch the tests

You will have this regarding the execution of first test

You will have this regarding the execution of the second test

A new Postgres instance is created and is in used. Previous one has been deleted.

Output of uname -a or ver

Linux 2a02-8428-dff8-c601-630e-0af7-4e92-5192.rev.sfr.net 6.16.10-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 2 19:23:55 UTC 2025 x86_64 GNU/Linux

Output of java -version

openjdk version "21.0.8" 2025-07-15 OpenJDK Runtime Environment (Red_Hat-21.0.8.0.9-1) (build 21.0.8+9) OpenJDK 64-Bit Server VM (Red_Hat-21.0.8.0.9-1) (build 21.0.8+9, mixed mode, sharing)

Quarkus version or git rev

3.22.1+

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

Apache Maven 3.9.9 (Red Hat 3.9.9-14)

Additional information

https://quarkus.io/blog/quarkus-3-22-1-released/

The sample is very simple. On some of my project I can have 10 TestProfiles with Oracle + Vault + Artemis ...
It can create 50 containers at start in initialization before running the tests. And it fails because I do not have enough resources.

Regards,

Damien

[quarkus-bot]

/cc @geoand (devservices), @holly-cummins (devservices), @ozangunalp (devservices)

[geoand]

Thanks a lot for reporting.

This is issue is known and I believe it is already tracked, right @holly-cummins ?

[vsevel]

this prevents our teams from upgrading to 3.27 :(

[holly-cummins]

Yes, this is covered by WG - Dev Services Lifecycle, and specifically the issue #45785. We also have sub-issues to track most core services, since each service needs to be updated individually.

There's a workaround which is to separate each profile into its own project, but of course that's not ideal.

For the OP, @dcdh , is it Oracle + Vault + Artemis services in your case? For @vsevel, which services is it which you need?

[vsevel]

which services is it which you need?

@holly-cummins for that particular application we were looking at with @dcdh, we are talking about these containers:

• oracle, which is the worst container in terms of startup time
• artemis
• our own smbj extension using elswork/samba:4.21.4
• vault (but we could disable that one)
• and ryuk of course

the application defines 22 @TestProfile , which is part of the issue.
we are going to alert the other dev teams about the behavior. I can't say at the moment if we will find other applications that may be bothered as well.
for that first application we are going to advise to say on 3.20 for now, and check for the next LTS next year.

[dcdh]

Hello @holly-cummins I confirm the stack Oracle, Vault, Artemis on my side. I have multiple containers of them at startup.

We have some internal custom devservice. Do you have a document on how to migrate them ?

Moreover, I have tested with a compose file for postgres and I have the same issue. Multiple postgres containers started at startup using compose.

[holly-cummins]

Hello @holly-cummins I confirm the stack Oracle, Vault, Artemis on my side. I have multiple containers of them at startup.

Noted, thanks. I will try and bump them to the top of the list. I'll do Oracle next.

We have some internal custom devservice. Do you have a document on how to migrate them ?

Most of the documentation has been just on issue discussions, but hot off the press, I've (finally!) drafted a migration guide: quarkusio/quarkusio.github.io#2460

Moreover, I have tested with a compose file for postgres and I have the same issue. Multiple postgres containers started at startup using compose.

Moving compose is on the list, but we will probably do a few others first, since compose is complex.

[holly-cummins]

@holly-cummins for that particular application we were looking at with @dcdh, we are talking about these containers:

* oracle, which is the worst container in terms of startup time

One thing to note is that we don't expect any more containers to be started, it's just that they're all front-loaded and started at the same time. It used to be we'd start a container for one profile, then stop it and start another when we moved to the next profile. Now we start all the containers at build time. So the overall elapsed time would be the same, but the high-water resource usage would be higher. (Starting all the containers at once could, if the system is tight on resources, cause thrashing which slows everything down, but more-time-spent-starting-containers isn't expected to be a direct consequence of the 3.22 changes.)

That means, for similar reasons, when I convert Oracle to the new model, the time spent starting containers will be about the same, you just won't ever look at the list of running containers and see six Oracle containers looking back at you.

[vsevel]

but more-time-spent-starting-containers isn't expected

@holly-cummins I confirm. that is what we see.

but the high-water resource usage would be higher

correct. that is exactly the issue we have. we had 8 profiles * 5 containers. it was taking for ever for sure. but the real blocking problem was that we would run out of resources before even starting the tests.

@dcdh reworked the app, and he was able to bring the number of profiles from 8 to 3 by using https://quarkus.io/blog/overriding-configuration-from-test-code/#approach-2-mocking-the-config-with-mockito, plus we deactivated the vault dev service, so we could bring the containers from 5 to 4.
so we are launching 3 profiles * 4 containers = 12, instead of 8 * 4 = 40.
so this is still a few containers to launch. but we brought it down enough now that resource wise it is manageable again.

we are still a little bit at risk on our CI, because we may have 5 builds running in parallel on the same node. assuming the app has 3 profiles and 4 containers, this means after 3.22 we are going to launch 12 containers per build and keep them up and running while we are running all tests. if 5 builds of that app on 5 feature branches run in parallel, this is going to be 60 containers. whereas before 3.22 this would be 4 containers per build at most, so 20 for 5 builds at any given time.

the resource requirement on dev machines and CI nodes really changes with that new behavior.

I do not believe dev teams are using test profiles that often. so that may not be an issue. in the early versions of quarkus, there was no mocking of configuration. so we used test profiles in app for that use case. now we see there are other options. we are going communicate to dev teams about that (e.g. do not use test profiles if there are other options).

on the good side of things, as we had this issue, it challenged us to bring down the number of containers and profiles, and now we have a build faster than the previous one :-)