Update to Testcontainers 2.0.2

[gsmet]

@gastaldi this includes all your work + a commit to work around the Strimzi issue. I got surprised that Debezium had it working and I gave it a try.

Note that there are probably things that wouldn't work but from my testing our use cases seems to somehow work. I did test only one Kafka module that uses the Strimzi container though.

Let's see how it goes.

[quarkus-bot]

/cc @loicmathieu (elasticsearch), @marko-bekhta (elasticsearch)

[gastaldi]

And this:

Suggested change

	<opensearch-testcontainers.version>2.0.2</opensearch-testcontainers.version>
	<opensearch-testcontainers.version>4.0.0</opensearch-testcontainers.version>

[gsmet]

Unfortunately, this version is Java 21+ so not sure what to do about it...

[marko-bekhta]

I wonder... how much do we actually need it ... since we already have some config of the container here:

quarkus/extensions/elasticsearch-rest-client-common/deployment/src/main/java/io/quarkus/elasticsearch/restclient/common/deployment/DevServicesElasticsearchProcessor.java

Lines 266 to 286 in 8862153

	private CreatedContainer createOpensearchContainer(ElasticsearchDevServicesBuildTimeConfig config,
	DockerImageName resolvedImageName, String defaultNetworkId, boolean useSharedNetwork) {
	OpensearchContainer container = new OpensearchContainer(
	resolvedImageName.asCompatibleSubstituteFor("opensearchproject/opensearch"));
	String hostName = ConfigureUtil.configureNetwork(container, defaultNetworkId, useSharedNetwork, DEV_SERVICE_OPENSEARCH);
	container.addEnv("bootstrap.memory_lock", "true");
	container.addEnv("plugins.index_state_management.enabled", "false");
	// Disable disk-based shard allocation thresholds: on large, relatively full disks (>90% used),
	// it will lead to index creation to get stuck waiting for other nodes to join the cluster,
	// which will never happen since we only have one node.
	// See https://opensearch.org/docs/latest/api-reference/cluster-api/cluster-settings/
	container.addEnv("cluster.routing.allocation.disk.threshold_enabled", "false");
	container.addEnv("OPENSEARCH_JAVA_OPTS", config.javaOpts());
	// OpenSearch 2.12 and later requires an admin password, or it won't start.
	// Considering dev services are transient and not intended for production by nature,
	// we'll just set some hardcoded password.
	container.addEnv("OPENSEARCH_INITIAL_ADMIN_PASSWORD", "NotActua11y$trongPa$$word");
	return new CreatedContainer(container, hostName);
	}

we might be able to just add another env variable to disalbe the security plugin ...
(just in case ... in Hibernate Search we just use a generic container and have specific settings for different versions of OpenSearch (https://github.com/hibernate/hibernate-search/blob/fcffca0a0a8bcaabe2ea74918925ce52ea463a5b/util/internal/integrationtest/backend/elasticsearch/src/main/java/org/hibernate/search/util/impl/integrationtest/backend/elasticsearch/SearchBackendContainer.java#L142-L172)

[gsmet]

Yeah, I'm experimenting with it as we speak to see what we can do.

[gsmet]

I kept the library and updated it a bit. I agree it doesn't have that much value but I didn't drop it.

What I did change is that our testing is now using the Testcontainers infrastructure as I needed that to check things were working and it's something @holly-cummins was working on anyway.

[github-actions]

🎊 PR Preview 5fe1704 has been successfully built and deployed to https://quarkus-pr-main-51314-preview.surge.sh/version/main/guides/

• Images of blog posts older than 3 months are not available.
• Newsletters older than 3 months are not available.

[gsmet]

OK, while Strimzi was not an issue, there are other issues related to kindcontainer so we will have to wait for a release there.

See:

• Bump to TestContainers 2.0.1 dajudge/kindcontainer#402
• Bump testcontainersVersion from 2.0.1 to 2.0.2 dajudge/kindcontainer#409

[holly-cummins]

I had an ickiness I needed to add in the JPA Postgres tests until we had Testcontainers 2, so I've pushed a commit which removes it, while I still remember it.

[gsmet]

This should be ready now.

[quarkus-bot]

Status for workflow Quarkus Documentation CI

This is the status report for running Quarkus Documentation CI on commit 24d7ac9.

✅ 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.

Warning

There are other workflow runs running, you probably need to wait for their status before merging.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 24d7ac9.

Failing Jobs

Status	Name	Step	Failures	Logs	Raw logs	Build scan
❌	JVM Tests - JDK 17	Build	Failures	Logs	Raw logs	🔍
❌	JVM Tests - JDK 21	Build	Failures	Logs	Raw logs	🚧
✔️	JVM Tests - JDK 21 Semeru			Logs	Raw logs	🚧
✔️	JVM Tests - JDK 25			Logs	Raw logs	🚧
❌	Quickstarts Compilation - JDK 17	Compile Quickstarts	⚠️ Check →	Logs	Raw logs	🚧

You can consult the Develocity build scans.

Failures

⚙️ JVM Tests - JDK 17 #

- Failing: extensions/smallrye-openapi/deployment 
! Skipped: devtools/bom-descriptor-json extensions/agroal/deployment extensions/elytron-security-jdbc/deployment and 57 more

📦 extensions/smallrye-openapi/deployment

❌ Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.4:test (default-test) on project quarkus-smallrye-openapi-deployment:

See /home/runner/_work/quarkus/quarkus/extensions/smallrye-openapi/deployment/target/surefire-reports for the individual test results.
See dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
There was an error in the forked process

---

⚙️ JVM Tests - JDK 21 #

- Failing: extensions/smallrye-openapi/deployment 
! Skipped: devtools/bom-descriptor-json extensions/agroal/deployment extensions/elytron-security-jdbc/deployment and 57 more

📦 extensions/smallrye-openapi/deployment

❌ Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.4:test (default-test) on project quarkus-smallrye-openapi-deployment:

See /home/runner/_work/quarkus/quarkus/extensions/smallrye-openapi/deployment/target/surefire-reports for the individual test results.
See dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
There was an error in the forked process

---

Flaky tests - Develocity

⚙️ 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

Details

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)

[rsvoboda]

I think this should have breaking change label and a note in https://github.com/quarkusio/quarkus/wiki/Migration-Guide-3.31

Motivation: Testcontainers 2 introduce change in GAVs and some packages

[geoand]

I think this should have breaking change label

It's definitely a breaking change, Quarkus LangChain4j for example fails on with this change. Adding the label as a result

[albers]

This also broke Quarkiverse CI for the Quarkus Azure Services: quarkiverse/quarkiverse#85

The extension is built against Quarkus 3.30.2 (which manages org.testcontainers:azure:1.21.3) but Quarkiverse CI tests against the current Quarkus snapshot (which manages org.testcontainers:testcontainers-azure:2.0.2).

/cc @majguo

[gsmet]

@majguo from my experience, the issues are mostly renaming artifacts but let me know if you encounter an issue. Quarkus 3.31 is planned for end of January. The Core artifacts to which you will be able to upgrade before the release will be published on January 21st.

[albers]

@gsmet It is only a matter of the 1.x dependency no longer being managed.
Fixing the dependency and nailing the version to 2.0.2 in the extension should do.