palantir/docker-compose-rule

Fail on Windows 7 with Docker 17

Opened this issue · 1 comments

Hi,

On Windows 7, with Docker Toolbox, Unit Tests don't succeed.

My docker version :

Client:
 Version:      17.03.0-ce
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   60ccb22
 Built:        Thu Mar  2 01:11:00 2017
 OS/Arch:      windows/amd64

Server:
 Version:      17.03.0-ce
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   3a232c8
 Built:        Tue Feb 28 07:52:04 2017
 OS/Arch:      linux/amd64
 Experimental: false

Actually, on each docker command I run, I have a line with this in beginning of my output :

time="2017-03-23T16:01:56+01:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"

Exemple on docker ps :

time="2017-03-23T16:01:56+01:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows"
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS               NAMES
11e76ecdf85e        mock_nexus          "/opt/lyra/bin/ent..."   10 seconds ago      Up 8 seconds        80/tcp, 443/tcp     sleepy_curran

This extra line causes an exception during execution, when output is parsed:

java.lang.IllegalArgumentException: No enum constant com.palantir.docker.compose.connection.State.time="2017-03-23T15:55:33+01:00" level=info msg="Unable to use system certificate pool: crypto/x509: system root pool is not available on Windows" 
HEALTHY
	at java.lang.Enum.valueOf(Enum.java:238)
	at com.palantir.docker.compose.connection.State.valueOf(State.java:18)
	at com.palantir.docker.compose.execution.Docker.state(Docker.java:66)
	at com.palantir.docker.compose.connection.Container.state(Container.java:112)
	at com.palantir.docker.compose.connection.waiting.ClusterHealthCheck.lambda$nativeHealthChecks$21(ClusterHealthCheck.java:56)
	at com.palantir.docker.compose.connection.waiting.ClusterWait.lambda$weHaveSuccess$22(ClusterWait.java:57)
	at com.jayway.awaitility.core.CallableCondition$ConditionEvaluationWrapper.call(CallableCondition.java:99)
	at com.jayway.awaitility.core.CallableCondition$ConditionEvaluationWrapper.call(CallableCondition.java:85)
	at com.jayway.awaitility.core.ConditionAwaiter$1.run(ConditionAwaiter.java:54)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

I tried to remove this line, and it's possible using command line option: --log-level=error.

I didn't find where I have to define it in my code using DockerComposeRule.

Maybe we need to add a way to give option or simply ignore this king of messages from docker.

The correct fix to this is not to set redirectErrorStream to true all the time.