-
Notifications
You must be signed in to change notification settings - Fork 64
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
bb_runner: Allow it to chroot into the input root #23
Comments
This was briefly disuccsed on the #buildstream IRC on gimpnet on 04/09/2019 by @juergbi and @kinnison.
|
Renamed this issue to explicitly mention the chroot use case. Stuff like respecting the |
When support for multiple runners for a single worker as added, we ran into a pretty serious design flaw: the cardinality between the number of build directories and runners had changed: 1:1 -> 1:*. Back then we sort of ignored this issue, which led interesting bugs, such as cleaning of the build directory not working properly in multi-runner setups. We eventually worked around this by disabling this feature. Some TODOs in cmd/bb_worker/main.go remained. The goal of this change is to finally tackle that problem by basically kicking out the Environment interface, which caused the 1:1 coupling. It introduces separate BuildDirectory and Runner types. LocalBuildExecutor now takes individual copies of each. Because of this decoupling, we can also fix #20. Builds are no longer performed in the build directory itself. Instead, they are run inside a subdirectory called "root". This makes it possible to use the top level directory for other purposes (e.g., storing stdout and stderr logs). It also partially addresses #23. The runner protocol has been extended to explicitly pass on the input root directory, so that a runner could chroot into it.
This should be easy to implement now. The runner protocol now has a dedicated field that provides you the input root directory: bb-remote-execution/pkg/proto/runner/runner.proto Lines 45 to 46 in 5df73f0
That is the directory in which you should chroot. |
We now have chroot support. 🎉 |
This comes as a proposal to implement behavior which is currently outside of the REAPI spec but is seen as an additional non standard platform property within RBE.
The proposal is that the worker/runner be provided with an optional platform property allowing the client to request that the action be executed within a sandbox within the input root. Currently this is the case but this is simply coincidental that the build directory is also the input root currently (See #20).
The text was updated successfully, but these errors were encountered: