running docker inside bazel test env on osx - macos

Question

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).
update: works on Linux
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.

Answer 1

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.

Answer 2

Seems like this does the trick:
$ bazel test --test_env=PATH < target >
It will be interesting to understand why it works in linux