-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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.
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
Host executable with non-empty DefaultInfo files missing from sandbox #7390
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
dslomov
added
team-Local-Exec
Issues and PRs for the Execution (Local) team
untriaged
labels
Feb 11, 2019
jmmv
added
type: bug
P2
We'll consider working on this in future. (Assignee optional)
and removed
untriaged
labels
Mar 3, 2019
This issue is still manifesting. In my case I have a py_binary being used as the executable for a custom rule:
when building the gen_sql target, on first run we get
but on second run, with no other changes, it runs happily. contents of rules.bzl:
|
Proposed fix: #10110 |
philwo
pushed a commit
that referenced
this issue
Nov 14, 2019
Fixes #7390 Summary: rules are allowed to set `DefaultInfo(files = depset(), executable = ...)`. If the resulting targets are used as tool inputs to another target, the executable will not be added to the downstream targets' action inputs. This manifests as either an `execvp()` error (from `ctx.actions.run()`) or a Bash error in genrules. This PR fixes that so the use case of non-default executables works as expected. This is useful for building scripts with complex runfiles, where `bazel run //:something` and `bazel build //:something && bazel-bin/something` cannot be supported by the same output file. cc @ccate @jmmv Closes #10110. PiperOrigin-RevId: 280170524
philwo
pushed a commit
that referenced
this issue
Nov 20, 2019
Fixes #7390 Summary: rules are allowed to set `DefaultInfo(files = depset(), executable = ...)`. If the resulting targets are used as tool inputs to another target, the executable will not be added to the downstream targets' action inputs. This manifests as either an `execvp()` error (from `ctx.actions.run()`) or a Bash error in genrules. This PR fixes that so the use case of non-default executables works as expected. This is useful for building scripts with complex runfiles, where `bazel run //:something` and `bazel build //:something && bazel-bin/something` cannot be supported by the same output file. cc @ccate @jmmv Closes #10110. PiperOrigin-RevId: 280170524
philwo
pushed a commit
that referenced
this issue
Nov 25, 2019
Fixes #7390 Summary: rules are allowed to set `DefaultInfo(files = depset(), executable = ...)`. If the resulting targets are used as tool inputs to another target, the executable will not be added to the downstream targets' action inputs. This manifests as either an `execvp()` error (from `ctx.actions.run()`) or a Bash error in genrules. This PR fixes that so the use case of non-default executables works as expected. This is useful for building scripts with complex runfiles, where `bazel run //:something` and `bazel build //:something && bazel-bin/something` cannot be supported by the same output file. cc @ccate @jmmv Closes #10110. PiperOrigin-RevId: 280170524
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Description of the problem / feature request:
Rules marked
executable = True
are allowed to return aDefaultInfo
with non-emptyfiles
, which means thatbazel build //some:exec
will print a different output path than what gets invoked bybazel run //some:exec
. This behavior is useful when writing rules for "script" binaries, when the content needed for hermetic execution might not function when copied outside of the Bazel execroot.However, when such a binary target is used in host mode (i.e. as a dependency of an action), Bazel will construct the sandbox filesystem incorrectly. The path passed to
execvp()
is different than the file present on disk.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
What operating system are you running Bazel on?
I can reproduce this bug on macOS and Linux, using the sandboxed strategy.
What's the output of
bazel info release
?release 0.22.0
Any other information, logs, or outputs that you want to share?
I edited
src/main/tools/process-wrapper-legacy.cc
tosystem("find .")
in the error path. The output shows the expected command being placed inrunfiles
:The text was updated successfully, but these errors were encountered: