Hey everyone,
We are currently developping software for Linux on either MacOS or Windows using Buildstream.
Given that Buildstream can run natively on Windows and MacOS but cannot build anything, we usually
ssh to a linux VM and do all our development from there or run BuildStream in a docker container, which introduces
an extra unneeded layer of sandboxing. That is far from ideal and we would
like to find a solution where we could ahve the tool installed natively and would run the builds transparently
on linux.
We therefore want to propose the usage of docker as a sandbox mechanism for Buildstream.
- Why add yet another sandbox mechanism ?
Currently BuildStream works on MacOS and Windows but cannot build locally. It can however use Remote Execution to do so.
We want to be able to use BuildStream on MacOS and Windows for doing linux builds and Bubblewrap cannot run on those platforms.
- Why docker ?
Docker is widely used, runs on all three platforms and would allow building for Linux on MacOS/Windows transparent to the user.
Moreover, it should have all the required capabilities that are needed to fully sandbox the build (network and filesystem isolation).
There are no other solutions that are cross platform and widely used (except for VMs, which is less practical to put in place)
- How that would be implemented ?
The aim is to have a second sandbox implementation, using docker that would behave similarily to the current bwrap sandbox.
We would introduce a "sandbox" parameter in the buildstream.conf user configuration that would default to "brwap" on linux and to "docker" on any other OS.
To me that makes sense. The defaults are debatable; we could detect whether bwrap or docker is present? It would be disappointing if docker is present on a Linux box
and BuildStream fails to run because bwrap isn't available.
- Questions to answer:
- How would we handle cache keys? Would docker and brwap sandbox considered equivalent and the cache keys match? Do we want a cache key per sandbox?
- We think a single cache key would be enough, if, and only if, we consider brwap and docker sandboxes "equal" in term of features.
There is a precedent for that: remote execution uses the same keys than the local ones.
I believe we should consider these equivalent, yes. If not we would need to rebuild everything when it hasn't been built with the same sandbox, which would be awkward.
Trust of sandboxes is gated by permissions on ArtifactCache - have it populated by trusted clients with trusted sandbox implementations.
Please let me know what you think about this proposal. I'll work on a proof of concept using docker as a sandbox in the meantime.
There is one other question to consider: should the alternative sandbox support be added to BuildBox instead, and by extension be usable. The question of cache keys then goes away.
Cheers,
Sander
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
