macOS remote execution - Aspect Build

Aspect Workflows runs macOS workers in the same remote execution cluster as your Linux workers, so bazel test //... distributes Apple-platform actions the same way it distributes everything else.

Available on Aspect Enterprise from Workflows 6.0: on EC2 Mac dedicated hosts on AWS, or on Mac machines you provide. Ask your Aspect contact whether your deployment has a macOS pool, or get in touch if you need one.

How the workers run

Bare-metal Mac hosts, on Apple Silicon or Intel, joining the cluster as native members alongside the Linux workers.
Several actions per host at once, so one long action doesn’t leave the rest of the machine idle.
Lazy input fetching through a virtual NFSv4 build directory: an action’s inputs come out of the CAS as it reads them, rather than the whole input tree being materialized first. That matters more on Apple platforms than anywhere else, because SDK and toolchain inputs are large and most actions touch a fraction of them.

Targeting a macOS pool

A macOS pool advertises OSFamily = Darwin. Your exec platform has to request exactly what the pool advertises: platform matching is whole-set equality, so copy the property set your Aspect contact gives you verbatim.

platforms/BUILD.bazel

platform(
    name = "macos_arm64_remote",
    constraint_values = [
        "@platforms//os:macos",
        "@platforms//cpu:arm64",
    ],
    exec_properties = {
        "OSFamily": "Darwin",
        # plus whatever else your pool advertises
    },
)

.bazelrc

build:rbe --extra_execution_platforms=//platforms:macos_arm64_remote

Then turn the rbe group on wherever the build reaches remote execution; the table in Targeting remote execution worker pools gives the line to add. Apple-platform builds usually need a mixed setup rather than a single exec platform: Linux actions on the Linux pool, Apple actions on the Mac pool, with Bazel’s toolchain resolution picking between them. See Targeting remote execution worker pools.

What to know before you plan a migration

Xcode has to match. Workers run a specific Xcode and SDK version. A build that depends on a different one needs the pool updated, which is a configuration change rather than something you do per-build. Pin your Xcode version in the repo so a mismatch fails loudly instead of producing different output on different machines.
Code signing is the usual blocker. Actions that need signing identities need those identities available to the worker. Plan to keep signing in a separate, later step rather than distributing it across the fleet on day one.
FileVault and CAS storage. Worker CAS storage is file-backed by default. FileVault blocks file-backed CAS, so a host where FileVault can’t be disabled uses an in-memory CAS instead, with a smaller effective cache and more refetching. Raise it early if your security policy mandates FileVault on all hardware.
Hermeticity gets tested harder. Apple toolchains reach for system state more readily than Linux ones. Actions that quietly depended on something on the local Mac fail on a worker. Budget time to fix them.

Capacity

Mac hosts don’t scale like Linux workers. On AWS, macOS runs on EC2 Mac dedicated hosts, which have a 24-hour minimum allocation period. A macOS pool can’t release a host within a day of allocating it, so size its floor and ceiling for sustained demand rather than bursts.
It’s the most expensive capacity in a deployment. It pays off where Apple-platform build and test time is on the critical path for everyone, and not where a couple of iOS targets build once a day.

Targeting remote execution worker pools: how exec platforms select a pool.
Remote execution: the cluster as a whole.
Configuration options: requesting a pool on a deployment hosted by Aspect.

​How the workers run

​Targeting a macOS pool

​What to know before you plan a migration

​Capacity

​Related

How the workers run

Targeting a macOS pool

What to know before you plan a migration

Capacity

Related