Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RUNFILES_MANIFEST_FILE is unset inside the sandbox #7994

Open
laszlocsomor opened this issue Apr 10, 2019 · 4 comments
Open

RUNFILES_MANIFEST_FILE is unset inside the sandbox #7994

laszlocsomor opened this issue Apr 10, 2019 · 4 comments
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug

Comments

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Apr 10, 2019 •
edited
Loading

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
@laszlocsomor laszlocsomor changed the title Linux, tests: RUNFILES_MANIFEST_FILE Linux, tests: RUNFILES_MANIFEST_FILE is unset Apr 10, 2019
@laszlocsomor
Copy link
Contributor Author

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
================================================================================

@laszlocsomor
Copy link
Contributor Author

Also, RUNFILES_DIR should not have a value with --noenable_runfiles.

@laszlocsomor laszlocsomor changed the title Linux, tests: RUNFILES_MANIFEST_FILE is unset Linux, sandboxed tests: RUNFILES_MANIFEST_FILE is unset Apr 10, 2019
@laszlocsomor laszlocsomor added category: sandboxing team-Local-Exec Issues and PRs for the Execution (Local) team untriaged labels Apr 10, 2019
@jmmv jmmv added P2 We'll consider working on this in future. (Assignee optional) type: bug and removed category: sandboxing untriaged labels May 23, 2019
@jmmv jmmv changed the title Linux, sandboxed tests: RUNFILES_MANIFEST_FILE is unset RUNFILES_MANIFEST_FILE is unset inside the sandbox May 13, 2020
@jmmv
Copy link
Contributor

jmmv commented May 13, 2020

Confirmed that this happens on macOS too, so fixed the title.

stephane-caron added a commit to upkie/vulp that referenced this issue May 6, 2022
@stephane-caron
Add argv0 to BulletInterface::Parameters
7b3ef03 
This value helps because Bazel does not seem to set the
RUNFILES_MANIFEST_FILE environment variable from cc_binary rules,
although it does that from py_binary rules that depend on
"@rules_python//python/runfiles". The following issues are related:

bazelbuild/bazel#4586
bazelbuild/bazel#7994
@laszlocsomor
Copy link
Contributor Author

Still repro'able with release 6.0.0-pre.20220608.2

@rickeylev rickeylev mentioned this issue Sep 5, 2024
Closed
github-merge-queue bot pushed a commit to bazelbuild/rules_python that referenced this issue Sep 5, 2024
@scasagrande @rickeylev
fix: make bootstrap_impl=script compute correct directory when RUNFIL…
65d1326 
…ES_MANIFEST_FILE set (#2177)

The script-based bootstrap wasn't computing the correct runfiles
directory when
`RUNFILES_MANIFEST_FILE` was set. The path it computed stripped off the
manifest
file name, but didn't re-add the `.runfiles` suffix to point to the
runfiles
directory.

To fix, just re-append the `.runfiles` suffix after it removes the
manifest file
name portion of the path.

Reproducing this is a bit tricky and it's difficult to reproduce the
necessary build
flags in a test; all of the following must be met:
* `--enable_runfiles=false`, but this cannot be set by transitions, only
via command line
* `--build_runfile_manifests=true` (this can be set in a transition, but
see below)
* Due to bazelbuild/bazel#7994, even if a
manifest is created,
the RUNFILES_MANIFEST_FILE env var won't be set _unless_ the test
strategy is local
  (i.e. not sandboxed, which is the default).

To work around those issues, the test just recreates the necessary
envvar state and
invokes the binary. The underlying files may not exist, but that's OK
for the code
paths were testing.

Fixes #2186

---------

Co-authored-by: Richard Levasseur <rlevasseur@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Local-Exec Issues and PRs for the Execution (Local) team type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jmmv @laszlocsomor