I'm running bazel inside of a docker container. Locally, when I run bazel with no flags I get the following warning:
WARNING: Sandboxed execution is not supported on your system and thus hermeticity of actions cannot be guaranteed. See http://bazel.build/docs/bazel-user-manual.html#sandboxing for more information. You can turn off this warning via --ignore_unsupported_sandboxing.
And while I lose some guarantees about hermeticity, Bazel still creates all the sandboxing directories before running any of my genrules.
However, in CI, I'm not seeing that warning and instead just get failures when sandboxing is attempted. So I passed --genrule_strategy=standalone to stop the crash, but now my genrules are executing right in the workspace, which I definitely don't want.
Is there a way for me to get the behavior I'm seeing locally, where explicit sandboxing calls are being disabled because they would fail but the tmp directory creation with srcs/deps/data being copied over correctly still happens?
Either a flag I could pass to bazel to trigger that behavior, or something I could do to my system to convince bazel that sandboxing is not supported there?
What bazel version are you using which crashes when it tries to use sandboxing? I suspect c2d773ef4c0916a44fd7936f7bbc22ec55102915 will resolve that problem because it makes the detection of whether the sandbox works much more robust, which seems like it would then do what you're looking for.
Two possible options:
1) To disable sandboxing, --genrule_strategy=standalone only applies to genrules. You also need to disable it for other rules, i.e. add --spawn_strategy=standalone. You may also need to disable it for specific rule types, e.g. --strategy GoCompile=standalone.
2) To use sandboxing, you can run Bazel inside a privileged container, i.e. start its container with the --privileged flag. This might be a configuration option in your CI.