Mentions légales du service

Skip to content

chore(deps): update org.testcontainers to v1.17.2

Renovate Tac requested to merge renovate/org.testcontainers into develop

This MR contains the following updates:

Package Change Age Adoption Passing Confidence
org.testcontainers:postgresql (source) 1.16.0 -> 1.17.2 age adoption passing confidence
org.testcontainers:junit-jupiter (source) 1.16.0 -> 1.17.2 age adoption passing confidence

Release Notes

testcontainers/testcontainers-java

v1.17.2

Compare Source

What's Changed

While this release had a major focus on stability, we managed to optimize the startup sequence and it should make your tests even faster!

Here is what it takes to have a Redis up and running with Testcontainers, end-to-end from the test's start to an instance ready to be connected: Before (1.17.1): 2.4s Before (1.17.2): 1.7s 🚀

And here is just the "initialize Testcontainers" measurements:

Before (1.17.1): 1102ms Before (1.17.2): 928ms

How we did it? We noticed that we can cache a couple of Docker responses, plus also removed now obsolete (yet expensive!) disk space check.

🚀 Features & Enhancements
🐛 Bug Fixes
📖 Documentation
🧹 Housekeeping
📦 Dependency updates

v1.17.1

Compare Source

What's Changed

🐛 Bug Fixes

📖 Documentation

v1.17.0

Compare Source

What's Changed

Highlights

This new version of Testcontainers comes packed with many new features and quality-of-life improvements, so we appropriately bumped the version to 1.17.0.

🐝 New Module: HiveMQ (#​4797) @​YannickWeber

Having started its Open Source life as its own 3rd-party Testcontainers library, we are very happy to welcome HiveMQ into the main repository. Now, using HiveMQ as part of your integration tests is as simple as a couple of lines of Java code:


@​Container
HiveMQContainer hivemq = new HiveMQContainer(DockerImageName.parse("hivemq/hivemq-ce:2021.3"));
hivemq.start();

Mqtt5BlockingClient client = Mqtt5Client.builder()
    .serverPort(hivemqCe.getMqttPort())
    .serverHost(hivemqCe.getHost())
    .buildBlocking();

client.connect();

Check out the docs to learn more about its many features!

💀 Ryuk JVM mode (#​4959) (#​4960) @​bsideup

Many Testcontainers user love the convenience Ryuk brings to Testcontainers: No matter what you do in your integration tests, Ryuk has got you covered and will cleanup all Docker resources created by Testcontainers after your test run is finished.

But some users operate Testcontainers in environments which do not support our container-based Ryuk implementation. So far their only option was to disable Ryuk alltogether.

Coming with this release, Testcontainers will now fallback to a JVM based resource-cleanup implementation in case of Ryuk being disabled. While this won't be as robust as the Ryuk container based implementation in all circumstances, it is nevertheless a great addition and acts as a useful compromise.

🚀 Features & Enhancements

🐛 Bug Fixes

📖 Documentation

🧹 Housekeeping

📦 Dependency updates

Click to expand...

v1.16.3

Compare Source

What's Changed
Highlights

Testcontainers 1.16.3 includes many changes, but there are two key highlights in this release:

k3s module (#​4582) @​rnorth, @​kiview

We've had plenty of feedback from users wanting to use Testcontainers to help test Kubernetes components. In particular, this is useful for people developing Kubernetes controllers/operators, who need something more than just a mocked Kubernetes API. In this release we're bringing the k3s module, which gives you a neat way to spin up the K3S lightweight Kubernetes inside of a container. We believe that k3s hits a sweet spot for ease of use and performance, so is a good option for testing Kubernetes components.

Now, launching a lightweight single-node Kubernetes cluster within your tests is easy as:

K3sContainer k3s = new K3sContainer(DockerImageName.parse("rancher/k3s:v1.21.3-k3s1"));
k3s.start();

String kubeConfigYaml = k3s.getKubeConfigYaml();
ApiClient client = Config.fromConfig(new StringReader(kubeConfigYaml));

// now use `client` to talk to your cluster!

Check out the docs to find out more!

Selenium 4 compatibility (#​4914) @​GannaChernyshova, @​tobiasstadler, @​kiview, @​rnorth

Selenium 4 was announced a while back, but we needed to make some changes to Testcontainers' Selenium/Webdriver module for compatibility. We're happy to announce that these changes have now been made, so you can now use Selenium 4 with Testcontainers!

As part of this upgrade we have to drop compatibility with Selenium 2, but believe that this will not have any practical impact.

🚀 Features & Enhancements
🐛 Bug Fixes
📖 Documentation
🧹 Housekeeping
📦 Dependency updates
Click to expand...

v1.16.2

Compare Source

What's Changed

1.16.2 fixes a race condition that was inadvertently added in 1.16.1. This bug can potentially cause unstable builds in some environments, manifesting as port wait timeouts at container startup.

🚀 Features & Enhancements

🐛 Bug Fixes

📖 Documentation

🧹 Housekeeping

v1.16.1

Compare Source

What's Changed

1.16.1 inadvertently introduced a race condition. This bug can potentially cause unstable builds in some environments, manifesting as port wait timeouts at container startup. We recommend upgrading to 1.16.2 or higher.

Testcontainers 1.16.1 has been released! 🎉

This release brings a lot of eagerly awaited new features and fixes, such as:

🔮 Better Oracle Database support

Thanks to the engagement of the community and @​gvenzl's new Docker images for Oracle Database Express Edition we were able to update our OracleContainer module to ensure its compatibility with a wide range of Oracle XE versions.

And at the same time, thanks to the new images, we were able to re-integrate the Oracle module into our CI. This means we can verify compatibility for using Testcontainers with Oracle Database going forward.

☁️ New Azure Cosmos DB module

With the new Azure Comos DB module we finally added Azure to our list of cloud service testing facilities. It is based on Microsoft's Azure Cosmos DB-Emulator and provides you with a way to do your integration testing without the need for an actual Azure service.

public CosmosDBEmulatorContainer emulator = new CosmosDBEmulatorContainer(
        DockerImageName.parse("mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:latest")
);

Please check out the module docs to learn how to use it for your integration testing needs.

⛴ Host port access for containers

For further improving the developer experience of our users, we added a new API to make hosts ports accessible to containers:

container.withAccessToHost(true)

You still need to use exposeHostPorts, as per the docs, but this can now be done after the container has started, thereby allowing new usage patterns in your tests.

🌪 Faster Cassandra startup

By making clever use of the configuration settings available in Cassandra, CassandraContainer will now start up to 3 times faster. It is now also configured to be less resource hungry out of the box.

✨ Better startup performance for all containers

We found a couple of ways to improve the container startup performance for our users, no matter the Testcontainers module you use. This comes through some internal changes with regards to how Testcontainers checks for open ports during container startup and will shave up to a couple of seconds from your test suite.

We are grateful for the ongoing support of our community and users and thank each of our awesome contributors!

🚀 Features & Enhancements

🐛 Bug Fixes

📖 Documentation

🧹 Housekeeping

📦 Dependency updates

Click to expand...

Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this MR and you won't be reminded about these updates again.

  • If you want to rebase/retry this MR, click this checkbox.

This MR has been generated by Renovate Bot.

Edited by Renovate Tac

Merge request reports