Reputation: 5037
Trying to run java_test
that runs docker
inside ProcessBuilder
.
To simplify the code of the test is as following:
@Test
public void testDockerExecutable(){
System.out.println("======== running docker ==============");
try {
Process p = new ProcessBuilder("docker","version")
.inheritIO()
.start();
} catch (IOException e) {
e.printStackTrace();
throw new RuntimeException(e);
}
}
Running docker version
straight from shell gives that output:
Client:
Version: 17.03.1-ce
API version: 1.27
Go version: go1.7.5
Git commit: c6d412e
Built: Tue Mar 28 00:40:02 2017
OS/Arch: darwin/amd64
Server:
Version: 17.03.1-ce
API version: 1.27 (minimum version 1.12)
Go version: go1.7.5
Git commit: c6d412e
Built: Fri Mar 24 00:00:50 2017
OS/Arch: linux/amd64
Experimental: true
But running the tests gives that output:
WARNING: Streamed test output requested. All tests will be run locally, without sharding, one at a time.
INFO: Found 1 test target...
JUnit4 Test Runner
.======== here ==============
java.io.IOException: Cannot run program "docker": error=2, No such file or directory
I know that I need to somehow import docker
to the runfiles environment (just like local_jdk
does). But how do I do that? Also - unlike jdk that only requires read permission, docker needs write permissions to it's lib
folder.
My env is mac os x sierra and bazel HEAD (68028317c1d3d831a24f90e2b25d1410ce045c54
).
tried it with java_test
. The "local"
attribute did not affect the failure. (tried it with both True and False).
I tried running this in linux and it works well both with "local"=True
and "local"=False
. Seems like it's something related to mac.
Upvotes: 2
Views: 393
Reputation: 3270
Linux sandbox mounts some directories by default (citing the docs):
We currently also mount /bin, /etc, /usr (except /usr/local), and every directory starting with /lib, to allow running local tools. In the future, we are planning to provide a shell with a set of Linux utilities, and to require that all other tools are specified as inputs.
I assume the docker binary is in one of the standard locations, and bazel finds it here.
Maybe on mac the binary is somewhere else and only exporting PATH to the test environment reveals it?
All aside, the best practice would be to make the test explicitly depend on some 'docker' target. Then bazel will make sure the binary is there. You can use local_repository (or its new_
variant) rules to hook it up.
Upvotes: 2
Reputation: 5037
Seems like this does the trick:
$ bazel test --test_env=PATH < target >
It will be interesting to understand why it works in linux
Upvotes: 0