Use buildbox-casd as remote execution proxy#1926
Conversation
juergbi
requested review from
BenjaminSchubert,
abderrahim,
cs-shadow and
gtristan
as code owners
|
How does this factor into the remote service tests ? It looks like Does this mean that this new codepath will be exercised in the buildgrid test with BuildBox 1.2.6+ in that image ? Should we EOL the older codepaths eventually and just have a hard dependency on BuildBox 1.2.6+ ? Maybe in 6 months ? Or should we extend the tests to ensure that we run them with older buildbox ? |
That's used for the worker container, which is not relevant to this PR. buildbox-casd used by BuildStream CI on the client side is taken from https://gitlab.com/BuildStream/buildstream-docker-images/, which uses the latest release from https://gitlab.com/BuildGrid/buildbox/buildbox-integration/. However, BuildStream CI uses a manually updated version from buildstream-docker-images, so this is actually still running with an old version of BuildBox. I'll push a commit to update the image for CI. (I did run the BuildStream BuildGrid tests locally with both older and updated BuildBox).
I think so, yes. I'd like to require BuildBox 1.2.8+ after some grace period to also ensure buildbox-run-bubblewrap drops all Linux capabilities (only relevant when running bst as privileged user) and include support for access tokens. |
buildbox-casd is already used as CAS and RA proxy. Using buildbox-casd for all remote connections aims to improve robustness (e.g., consistent retry behavior) and enables support for token-based authentication.
+1 |
2 participants
buildbox-casd is already used as CAS and RA proxy. Using buildbox-casd for all remote connections aims to improve robustness (e.g., consistent retry behavior) and enables support for token-based authentication (#1913).
This depends on BuildBox 1.2.6+ for the remote execution proxy to be used. However, BuildStream will fall back to direct gRPC connections if buildbox-casd doesn't support execution remotes.