More than binary option of sandbox?

[njskalski]

Right now, a job can be "sandboxed" or "not sandboxed". I have multiple sandboxes, ranging from default, through docker-based down to qemu one. Depending on the job, I need different levels of isolation - there is no point of starting up qemu to run a small bash script.

Would it be possible to create a "named sandbox switch" as opposed to just "true" and "false" and 1 global option?

Kind Regards

[toastwaffle]

Hey @njskalski. Just to confirm, you're talking about different build targets using different sandboxes, rather than different invocations of plz? The latter could be solved with having different config profiles (e.g. .plzconfig.qemu_sandbox specifying the different sandboxes, and then invoking something like plz --profile=qemu_sandbox build //some/target/neeting:qemu

If it is the former, it would in theory be possible to add a parameter to the base build_rule allowing the sandbox binary to be specified on a per-target level, but the bigger problem would be updating all of the plugins and build defs to allow specifying that argument and passing it down to the build_rule calls.

[njskalski]

Yes, exactly. While some targets I need to have fully isolated, there is no point in starting a vm for a zip download or git checkout. And disabling sandbox for a wide number of jobs "somewhere in between" kills a huge feature of Plz.

Just changing the type of "sandbox" argument from bool to int (0 meaning "no isolation") would enable this use case.

Being able to "override sandbox function" at job level by wrapping it in something would also work.

I can fake the feature by just making a function that delegates to right sandbox implementation depending on some job variable. But I think ability implement sandbox so easily is one of the coolest features of Plz I have seen and leveraging that would be a huge selling point, especially to enable complex tests.