Chromium

Chromium's build system shells out to Siso, which speaks the Remote Execution API. Pointing it at a NativeLink cluster is a configuration change, with no patches to the Chromium tree.

The same pattern works for upstream Chromium and any Chromium-based browser.

Prerequisites

• A NativeLink cluster reachable from your build machines. Cache-only is fine to start; remote execution drops build times further.
• A Chromium checkout with depot_tools on $PATH.
• The Chromium source checkout (fetch chromium).

Configure Siso

Siso reads its server settings from environment variables. Add to your build shell:

export SISO_REAPI_ADDRESS=cas.nativelink.internal:50051
export SISO_REAPI_INSTANCE=main
export RBE_service_no_security=false   # mTLS in production
export RBE_tls_client_auth_cert=/etc/nativelink/tls/client.crt
export RBE_tls_client_auth_key=/etc/nativelink/tls/client.key
export RBE_tls_ca_cert=/etc/nativelink/tls/ca.crt

SISO_REAPI_INSTANCE must match an instance_name your NativeLink server exposes. The repository's own Chromium example uses the default empty instance name (SISO_REAPI_INSTANCE='') and also sets SISO_REAPI_CAS_ADDRESS to the same endpoint: deploy/chromium-example/build_chromium_tests.sh.

For local development against a non-TLS NativeLink:

export SISO_REAPI_ADDRESS=localhost:50051
export SISO_REAPI_INSTANCE=main
export RBE_service_no_security=true

Generate Chromium build files

In your Chromium checkout:

gn gen out/Default --args='
  use_remoteexec=true
  use_siso=true
'

autoninja reads args.gn; with use_siso=true, it invokes siso ninja for the build.

Build

autoninja -C out/Default chrome

Watch the build go. On a fresh cluster the first build will be mostly misses; subsequent builds hit the cache and run in a fraction of the time.

What good looks like

• Cache hit rate: on a warm cache the hit rate for an incremental build should be high and climb from build to build; watch it in the NativeLink cache metrics.
• Local fallback rate: close to zero. Anything higher means workers are rejecting actions (platform mismatch, capacity).
• Network errors: zero. Anything else is a problem.

Worker requirements

Chromium's Siso config takes its remote platform properties from build/config/siso/backend_config/backend.star (copy template.star and edit it, or point the reapi_backend_config_path gclient custom var at your own file). Each platform entry names an OSFamily and a container-image, and every NativeLink worker that should run Chromium actions must advertise the same values, with the property key spelled container-image (hyphen).

The repository ships a Chromium worker image built from Chromium's public siso-chromium/linux RBE image, and a kustomization that deploys it alongside a NativeLink cluster:

• deploy/chromium-example/ for the deployment,
• kubernetes/workers/siso-chromium/kustomization.yaml for the worker, which uses the shared worker config in kubernetes/components/worker/worker.json5 (OSFamily: Linux, container-image from the worker image, cpu_count from nproc).

Troubleshooting

• All actions falling back to local. Likely a platform-property mismatch. Compare what Chromium is requesting (in the siso log) against what your workers advertise.
• Siso is not being selected. If the output directory was already generated for Ninja, run gn clean out/Default, regenerate with use_siso=true, and build again.
• Cache writes succeed, reads always miss. Almost always a toolchain version mismatch between the action that wrote the cache and the one trying to read.

FAQ