[Enhancement]: Wait strategy - auto detect system

[Kielek]

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:
open-telemetry/opentelemetry-dotnet-instrumentation#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:

testcontainers-dotnet/src/Testcontainers/Clients/DockerSystemOperations.cs

Lines 18 to 23 in d3f09da

	public async Task<bool> GetIsWindowsEngineEnabled(CancellationToken ct = default)
	{
	var version = await GetVersionAsync(ct)
	.ConfigureAwait(false);
	return version.Os.IndexOf("Windows", StringComparison.OrdinalIgnoreCase) > -1;
	}

Would you like to help contributing this enhancement?

Yes (if changes are simple)

[HofmeisterAn]

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

testcontainers-dotnet/src/Testcontainers.MongoDb/MongoDbBuilder.cs

Lines 110 to 125 in c8a44a7

	private sealed class WaitUntil : IWaitUntil
	{
	private static readonly string[] LineEndings = { "\r\n", "\n" };
	/// <inheritdoc />
	public async Task<bool> UntilAsync(IContainer container)
	{
	var (stdout, stderr) = await container.GetLogsAsync(timestampsEnabled: false)
	.ConfigureAwait(false);
	return 2.Equals(Array.Empty<string>()
	.Concat(stdout.Split(LineEndings, StringSplitOptions.RemoveEmptyEntries))
	.Concat(stderr.Split(LineEndings, StringSplitOptions.RemoveEmptyEntries))
	.Count(line => line.Contains("Waiting for connections")));
	}
	}

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.