bazel
bazel copied to clipboard
RUNFILES_MANIFEST_FILE is unset inside the sandbox
Description of the problem / feature request:
Bazel does not set RUNFILES_MANIFEST_FILE
for tests when it should.
Update: only with sandboxing.
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
BUILD
:
sh_test(
name = "x",
srcs = ["x.sh"],
data = ["BUILD"],
)
x.sh
:
#!/bin/bash
env | grep "^RUNFILES_.*="
When runfiles symlinks are enabled, all works fine: RUNFILES_DIR
is defined, RUNFILES_MANIFEST_*
isn't.
$ bazel test --enable_runfiles --build_runfile_manifests -t- --test_output=all //:x
...
==================== Test output for //:x:
RUNFILES_DIR=/usr/local/google/.../x.runfiles
================================================================================
When runfiles symlinks are disabled, RUNFILES_MANIFEST_FILE is missing:
$ bazel test --noenable_runfiles --build_runfile_manifests -t- --test_output=all //:x
...
==================== Test output for //:x:
RUNFILES_MANIFEST_ONLY=1
RUNFILES_DIR=/usr/local/google/.../x.runfiles
================================================================================
What operating system are you running Bazel on?
Debian
What's the output of bazel info release
?
release 0.24.0
The bug only affects sandboxed execution.
Without sandbox:
$ bazel clean ; bazel test --noenable_runfiles --build_runfile_manifests --spawn_strategy=standalone -t- --test_output=all //:x
...
==================== Test output for //:x:
RUNFILES_MANIFEST_ONLY=1
RUNFILES_MANIFEST_FILE=/usr/local/google/.../x.runfiles/MANIFEST
RUNFILES_DIR=/usr/local/google/.../x.runfiles
================================================================================
With sandbox:
$ bazel clean ; bazel test --noenable_runfiles --build_runfile_manifests -t- --test_output=all //:x
...
==================== Test output for //:x:
RUNFILES_MANIFEST_ONLY=1
RUNFILES_DIR=/usr/local/google/.../x.runfiles
================================================================================
Also, RUNFILES_DIR
should not have a value with --noenable_runfiles
.
Confirmed that this happens on macOS too, so fixed the title.
Still repro'able with release 6.0.0-pre.20220608.2