No waitingFor() method in DockerComposeContainer #174

Activity

1. rnorth commented on Jul 16, 2016

   

   rnorth

   on Jul 16, 2016

   Member

   More actions

   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
2. ldcasillas-progreso commented on Jul 18, 2016

   

   ldcasillas-progreso

   on Jul 18, 2016

   Author

   More actions

   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.
3. rnorth

   modified the milestones: 1.1.3, 1.1.4 on Jul 19, 2016
4. rnorth commented on Aug 16, 2016

   

   rnorth

   on Aug 16, 2016

   Member

   More actions

   Sorry this didn't make it into 1.1.4 :(
5. rnorth

   removed this from the 1.1.4 milestone on Aug 16, 2016
6. outofcoffee commented on Nov 19, 2016

   

   outofcoffee

   on Nov 19, 2016

   Contributor

   More actions

   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 ?
7. rnorth commented on Nov 20, 2016

   

   rnorth

   on Nov 20, 2016

   Member

   More actions

   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?
8. outofcoffee commented on Nov 20, 2016

   

   outofcoffee

   on Nov 20, 2016

   Contributor

   More actions

   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'.
9. edgarvonk commented on Feb 11, 2017

   

   edgarvonk

   on Feb 11, 2017

   More actions

   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.

   👍React with 👍2Reacted by Andrea Arcuri and Réda Housni Alaoui
10. barrycommins commented on Aug 12, 2017

    

    barrycommins

    on Aug 12, 2017

    Contributor

    More actions

    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

    👍React with 👍5Reacted by Edgar Vonk, Kunal Kapoor, Andrea Arcuri, Sergei Egorov and İlkin Balkanay
11. bsideup commented on Feb 22, 2018

    

    bsideup

    on Feb 22, 2018

    Member

    More actions

    Hi @barrycommins,
    I really like the idea :) Do you want to contribute it?
12. barrycommins commented on Feb 22, 2018

    

    barrycommins

    on Feb 22, 2018

    Contributor

    More actions

    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.
13. kiview commented on Feb 24, 2018

    

    kiview

    on Feb 24, 2018

    Member

    More actions

    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.
14. bsideup

    added a commit that references this issue on Mar 19, 2018

    Support for WaitStrategy on DockerComposeContainer - alternative appr…

    ...

    8558203
15. bsideup

    added

    area/docker-compose

    type/feature

    on Mar 19, 2018
16. bsideup

    added this to the next milestone on Mar 19, 2018
17. bsideup

    added

    resolution/awaiting-release

    on Apr 6, 2018
18. bsideup commented on Apr 7, 2018

    

    bsideup

    on Apr 7, 2018

    Member

    More actions

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

    closed this as completedon Apr 7, 2018