testcontainers-dotnet
testcontainers-dotnet copied to clipboard
[Enhancement]: Wait strategy - auto detect system
Problem
In OpenTelemetry Automatic Instrumentation for .NET we execute a lot of integration tests based on test containers. Typical scenario is to execute
- Windows containers on Windows
- Linux containers on Linux.
In case of release we extend cases and execute tests also on Windows with Docker for Linux.
There is no easy way to determine which scenario we executing. It can leads to hanging tests if you use Wait.ForWindowsContainer()
on Windows with Docker for Linux.
Details: https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/issues/2715
Solution
Create easy way to detect/auto detect appropriate Wait strategy.
Consider
Wait.ForAutoDetectedContainer()
method.
Benefit
No manual changes/custom code be written by the users. Code can be executed on all supported cases.
Alternatives
Make method similar to publicly available: https://github.com/testcontainers/testcontainers-dotnet/blob/d3f09da08f0709225e254c0b39e6b187fdc0bb75/src/Testcontainers/Clients/DockerSystemOperations.cs#L18-L23
Would you like to help contributing this enhancement?
Yes (if changes are simple)
In case of release we extend cases and execute tests also on Windows with Docker for Linux.
If I got you right, you want to run the tests against Linux and Windows containers using the same container builder configuration?
It can leads to hanging tests if you use Wait.ForWindowsContainer() on Windows with Docker for Linux.
Yes, because it runs a PowerShell command against a Linux container that never succeeds.
Have you tried the MongoDB module? I am not sure if the module's wait strategy is compatible with the Windows image, but it just checks the console output (log messages).
https://github.com/testcontainers/testcontainers-dotnet/blob/c8a44a793039cb8bedb0b379226789a2a8e22b8b/src/Testcontainers.MongoDb/MongoDbBuilder.cs#L110-L125
Relying on the port like the MongoDBCollection does is not sufficient for MongoDB to indicate readiness. Checking the console output may work for both container engines and is recommended.
Regarding the issue, probably the best is to expose either the client or its container runtime information.