Hi all, Some updates on the proposal based on the comments from another post.
Le mar. 10 déc. 2024 à 10:14, Abderrahim Kitouni <[email protected]> a écrit : > ### Execution > > Remote execution is another service that is part of this set of APIs. > The way buildstream currently works with remote execution is that it > sends the whole build to be executed remotely. In that case, we don't > have control over what runner it is going to run in and can't expose a > socket like this unless we manage to convince the remote-apis folks to > add an option to do this. When running locally, recent versions of > buildbox-casd implement a remote execution server that runs things > locally, but this isn't enabled by default (and buildstream doesn't > enable it either). This leaves us with no way to run things using > remote execution. A few things to add here. We don't have to only use standard platform properties. Buildbox already supports some additional platform properties (such as chrootRootDigest) that we can use. We can potentially have a new platform property for buildbox, even if it's not standardized (and we can consider standardizing things later on). So if this is agreeable to the buildbox folks, we can add a new platform property that exposes a unix socket with the same semantics defined in this proposal. We can then use remote execution this way: * enable local "remote execution" when starting buildbox-casd * use the proposed platform property to make the casd socket available in the sandbox * software running in the sandbox (e.g. recc or bazel) can use this to "remotely" execute their actions. These would run on the local executor in buildbox-casd. When remote execution is enabled, we would need the remote execution service to have something that supports this platform property. There is probably something to be done with new buildbox-casd features. It supports some fancy combination of local and remote executors that we can maybe find useful. Does this make sense? Abderrahim
