--remote_executor, so hundreds of compile and test actions run in parallel whatever the local hardware.
Every action with no unmet dependencies runs as soon as a worker is free, instead of queuing behind other actions on one machine. The fleet implements the Bazel Remote Execution API v2, so any REv2 client works with it.
What the fleet offers
- Several platforms side by side. Each executor runs its own container image, with worker pools of its own instance type,
amd64orarm64, and GPU pools. One build can mix images, OS versions and toolchains without splitting into separate jobs. - Native cross-platform builds. Multi-arch container publishing and other cross-platform work run on the right architecture rather than through emulation.
- Auto-scaling to zero. Pools scale on queue depth and scale down to zero when the queue is empty. They can also pre-scale on a schedule ahead of expected load.
- Docker-based tests on the workers.
- Workers on your own hardware. Machines you run yourself can join the fleet as remote execution workers, for any worker type.
Where it’s available
Remote execution is available on Aspect Enterprise today and is coming soon to Aspect Cloud. On Aspect Enterprise it runs hosted by Aspect or self-hosted, with Linux workers, macOS workers, and GPU workers. Until it reaches Aspect Cloud, an Aspect Cloud build runs its actions on your own machines, with the shared remote cache in front of them. You can start with CI runners and remote cache, and turn remote execution on later as a configuration change on the same deployment.Configuring your repository
Remote execution is never on by default: it changes where every action runs.
Each action also needs an exec platform whose
exec_properties match a worker pool exactly, and a toolchain that runs on that pool’s image. RBE platforms covers the matching rule, and Parallelize remote execution covers getting more actions in flight.