Ability to use local Docker compose binary instead of container.

[outofcoffee]

Purpose

Adds the ability to use local Docker compose binary instead of container.

Rationale

In scenarios where tests are running within a container (such as using Jenkins Docker Plugin), it is difficult for the docker-compose.yml file to be bind mounted into the internal Docker compose container used by the current DockerComposeContainer implementation.

Implementation

Key methods from DockerCompose have been extracted to an interface, and a second implementation, LocalDockerCompose has been added that uses the docker-compose on the PATH.

Users call the withLocalCompose() method on DockerComposeContainer to activate this behaviour.

[rnorth]

Should this timeout be longer, especially to allow for pulling/building of containers..?
I'm not sure there's actually any easy timeout length, so maybe just let it be infinite?

[qoomon]

I think it shouldn't be done with an explicit call. I would prefer to do it with an environment variable. We than can run the same java source within different environments without adopting the test to specific environment.

[rnorth]

@qoomon good point. How about we make withLocalCompose() require a boolean value to be passed to turn this behaviour on/off?

That way users would be free to define an environment variable (rather than us dictating one) and use that. Alternatively they could just pass in true if there's something about their usage that means this behaviour is always desired. What do you think @outofcoffee ?

[qoomon]

I dont like the idea to check out a project and then are not be able to run all test because of environment dependencies. Therefore i would like to keep dependencies at a bare minimum.
Maybe another solution could be to fall back to compose container if withLocalComose() is set.

[qoomon]

And i think the problem described is already solved by #189

[rnorth]

What do you think of #189 @outofcoffee? Does this PR address a different
issue?
On Mon, 15 Aug 2016 at 23:17 Bengt Brodersen [email protected]
wrote:

And i think the problem described is already solved by #189
#189

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#200 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIET9Nrss9l6RNup_0tHn0flp-HxcPnks5qgOV5gaJpZM4Jhprs
.

Richard

[outofcoffee]

@rnorth #189 solves something different. In this scenario, PWD resolves to a path within the current container; namely the one running the JUnit test. That path is not going to be accessible to the Compose container, so Compose can't see the YAML file.

Mounting a volume is also impractical as a work around due to the issue of the buildup of garbage with containers having different lifecycles (compose and the test host container).

In short, no, it doesn't work for this scenario.

[outofcoffee]

@rnorth rebased on master and:

• switched to zt-exec
• added check for binary and fails fast if not present
• cleaned up exit value check
• set timeout to infinite, as suggested
• tidied up a bit
• made withLocalCompose accept a boolean

[rnorth]

@outofcoffee sorry for the numerous delays in looking at this. I will merge. However, please could you rebase onto master and solve the current merge conflicts?

[pcornish]

@rnorth - passed on Travis, but CircleCI failed with:

org.testcontainers.containers.ContainerFetchException: Retry limit reached while trying to pull image: mysql:5.5

:-/

[rnorth]

@pcornish thanks. Docker pull issue = :z
Merging, as this failure is an intermittent one.