|
Fellow BuildStreamers We have talked about using the BuildBox sandbox as BuildStream's local sandbox in the past. I believe the consensus was that we would remove all other sandboxes and just have the Dummy, Remote and BuildBox sandboxes. Juerg created https://gitlab.com/BuildStream/buildstream/merge_requests/951 6 months ago and I have now re-based and started updating it. I have a branch that now passes the tests locally and I have a new test stage that passes CI. Having spoken to some members of our community I believe that rather than removing all the old sandboxes and adding the new one in one go, we should aim to do this over a number of MRs, but make sure that all are landed before bst2.0. I propose: ========== * Update !951 to add the BuildBox sandbox but set it to only work if requested by the user (please see below for details.). * Once !951 lands we can all try it out and create issues for any problems that come to light during this testing. * Create and merge MRs for any outstanding items on the existing issue #719 and for the issues arising from wider testing. * Once we are happy with the new sandbox, and we have resolved any issues which arise with the distribution and availability of BuildBox for our developers and future users, we can remove the other sandbox implementations. If this plan is acceptable I imagine the first MR would cover: ============================================================== * The first implementation of the new sandbox. * Report nice errors rather than bugs for those trying out the new sandbox, if they use parts that are not finished, for example: - warning due to limited bst shell support - error for element plugins that don't support the virtual directory API - error for elements requiring non-0 UID/GID - error when BuildBox is not available. * The BuildBox sandbox should only be used if explicitly enabled. I will implement this option with the existing option code paths as much as possible. Eg, environment Var, maybe also user settings file and CLI if they prove to be easy to add, I do not see this as a project level setting. - We currently have BST_FORCE_BACKEND, I will add BST_FORCE_SANDBOX etc. * For the first MR I propose that most of our existing `test stages` in gitlab-ci.yml continue to test the old sandbox, but we add a new test stage in gitlab-ci.yml. The other `test stage` (tests-unix) that does not use the current sandbox alters the installed environment in the `script` section of its stage in gitlab-ci.yml. I have mirrored this pattern for my BuildBox branch and added the BuildBox install instructions to the `script` section of my new test stage in gitlab-ci.yml. * If the above point is acceptable then before the MR lands I will create a issue to create new docker images that include BuildBox, and link it to the MR. * These new images can then be tested outside of master, and when we create the MR to remove the old sandboxes we can update the Docker images linked to by the CI, as we change the sandbox that gets tested. Note: AFAIK, currently BuildBox is not packaged for any OS. So a step towards getting to the point where we can remove the old sandboxes may be updating the install procedure for BuildStream master to include BuildBox. The first MR would try to cover much of https://gitlab.com/BuildStream/buildstream/issues/719 but not everything, but the other sandboxes would not be removed until all of the TODOs in #719 were complete. While I appreciate that the timing will be more drawn out than first hoped, I hope getting everything changed over by bst2.0 should keep the spirit of the original plan. Will |