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 — no patches to the Chromium tree.

The Samsung Internet team runs this configuration in production for their browser fork; 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=chromium
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

For local development against a non-TLS NativeLink:

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

Generate Chromium build files

In your Chromium checkout:

gn gen out/Default --args='
  use_remoteexec=true
  use_goma=false
  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: 85-95% on incremental builds; 60-80% on full builds, visible from NativeLink cache metrics.
• Local fallback rate: under 1%. Higher means workers are rejecting actions (platform mismatch, capacity).
• Network errors: zero. Anything else is a problem.

Worker requirements

Chromium actions have specific platform requirements. Your worker config should advertise:

• container_image: chromium-build-base:<version>
• OSFamily: linux
• cpu_count: 8 (minimum; 16+ recommended for link steps)

The deploy/chromium-example/ directory in the source tree has the worker config Samsung uses.

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.

What's next

• Persistent workers for the hot toolchain paths.
• Metrics — Chromium builds produce a lot of telemetry; have the dashboards ready.