No waitingFor() method in DockerComposeContainer

[ldcasillas-progreso]

Using version 1.1.0, the DockerComposeContainer class no longer extends from GenericContainer and thus doesn't have anything like the waitingFor method.

Related issues:

• Add support to follow containers logs with DockerComposeContainer #158
• [WIP] Docker compose refactor #156

[rnorth]

Hi Luis

Yes, I'll reinstate. I'm afraid I'd not anticipated that use case.

I imagine you must be relying on a call to getServicePort in your
WaitStrategy. Is that correct? If so I'll need to take a little care to
ensure that also works.

If you could possibly share some demo code for how you're using this it
would help me make sure compatibility is retained!

Thanks

Richard

Richard

[ldcasillas-progreso]

Because of problems with DockerComposeContainer in 1.0.5 I was just not using it at all—I was manually coordinating multiple GenericContainers. So I don't have a code example that's regressed between 1.0.5 and 1.1.0, or any backwards compatibility constraints.

[rnorth]

Sorry this didn't make it into 1.1.4 :(

[outofcoffee]

Suggest we move waitingFor to its own interface, implemented by both GenericContainer and DockerComposeContainer. In the latter case, the implementation could make use of the listChildContainers method and apply the WaitStrategy to each of them.

Thoughts @rnorth ?

[rnorth]

Potentially @outofcoffee; I can see there being some complication in needing different wait strategies for different child containers. So we'd need a way of telling testcontainers which wait strategy corresponds to which service, wouldn't we?

[outofcoffee]

Agree; I've implemented this by abstracting the port exposure stuff into a higher level 'EndpointBuilder', which works like this:

// Fetch an EndpointBuilder from container/compose container
EndpointBuilder endpointBuilder = container.newEndpointBuilder();

endpointBuilder.add("my-service")
    .withExposedPort(...)
    .waitingFor(...);

// add further endpoints

endpointBuilder.build();

When calling EndpointBuilder.add() an intermediary state holder, Endpoint is returned and registered in the builder. Calling build() iterates over these and handles the logic of orchestrating the calls to the containers to set up ports and wait strategies etc.

To do this, Endpoint, GenericContainer and DockerComposeContainer implement an interface with methods like 'waitingFor', 'withExposedPort' and 'getMappedPort'.

[edgarvonk]

Hi all, are there any updates on this maybe? This feature would greatly help us because we need to wait until certain events have taken place until we can start our component tests.

[barrycommins]

I've been having a quick look at this, and was wondering would it be a good idea to add an overloaded withExposedService() method with a WaitStrategy parameter on DockerComposeContainer?

Something like:

public SELF withExposedService(String serviceName, int servicePort, @NonNull WaitStrategy waitStrategy)

Example usage:

new DockerComposeContainer(new File("test-compose.yml"))
    .withExposedService("redis_1", 6379, Wait.forListeningPort())
    .withExposedService("elasticsearch_1", 9200, Wait.forHttp("/all").forStatusCode(200));

The HttpWaitStrategy should work fine, but I'm not sure how the others would work with the AmbassadorContainer

[bsideup]

Hi @barrycommins,
I really like the idea :) Do you want to contribute it?

[barrycommins]

Hi @bsideup,

I looked at this a like bit at the time. I think things are a little complicated due to the use of Ambassador containers.

I think it'd be easy enough to apply WaitStrategy to the Ambassador containers, but more difficult to apply them to the proxied containers, which is what you'd really need.

This is a feature I'd really like though, so I'll try to get back to it in the next couple of weeks, and see what's possible.

[kiview]

Hey @barrycommins, just as a heads up, the old ambassador container has been changed to SocatContainer in Testcontainers 1.6.0, which is a simpler design I think and is a very transparent proxy.

[bsideup]

Released in 1.7.0 (already in Bintray's JCenter, will be synced with Maven Central soon)