Configure remote execution

Choose the execution service

Hermetiq can observe remote execution connected to an existing Buildbarn environment and can support managed remote-execution onboarding for eligible projects. The endpoint, instance, credentials, worker platforms, and capacity are deployment-specific.

Configure Bazel

Set --remote_executor to the execution frontend and use the instance name required by that service. Keep the flags in an explicit configuration until the integration is verified.

# Structure only: use the values supplied for your project
build:hermetiq-rbe --remote_executor=<RBE_ENDPOINT>
build:hermetiq-rbe --remote_instance_name=<INSTANCE_NAME>

# Repeat this flag for the properties required by your execution platform
build:hermetiq-rbe --remote_default_exec_properties=<NAME>=<VALUE>

Activate these scoped entries with --config=hermetiq-rbe. If you choose a different configuration name, use that name consistently in local and CI commands.

Use the credential-helper host mapping generated for the project or supplied by the customer-managed administrator. If the deployment uses separate cache and executor endpoints, ensure the helper covers every authenticated host and configure the matching remote cache explicitly.

Match instance and authentication

• The --remote_instance_name value must identify the storage and execution namespace assigned to the project.
• The machine credential must be authorized for that project and for the executor, cache, CAS, or Bytestream hosts it contacts.
• Use grpcs:// when the service requires TLS. Install the required trust chain rather than disabling certificate validation.
• For customer-managed RBE, follow the deployment’s OAuth, mTLS, or metadata convention; not every deployment enables every authentication method.

Authentication success does not guarantee access to the requested instance. A credential can be valid while the instance name or routing metadata is wrong.

Match execution platforms

Remote schedulers match actions to workers using platform properties. The Buildbarn or managed-service operator should publish the supported operating system, architecture, container image or worker pool, and any custom property names and values.

• Set only properties the scheduler recognizes, using the exact spelling and values supplied by the operator.
• Use Bazel execution platforms and toolchain constraints when different targets require different workers.
• Keep target and exec-platform constraints separate: a target may produce one platform’s output while its tools run on another.
• Verify that worker capacity exists for every property combination emitted by the build.

Make actions portable

A remote worker does not automatically have the tools installed on the Bazel client. Actions should declare their tools and inputs through Bazel toolchains, repositories, runfiles, or the execution environment agreed with the RBE operator.

• Avoid undeclared reads from the client filesystem, home directory, or host-specific absolute paths.
• Do not assume the worker image contains a compiler, shell, SDK, certificate bundle, or system package unless the platform contract says it does.
• Keep environment-dependent values explicit and stable when they affect action keys.
• Test representative targets, tests, code generation, and packaging workflows before moving all CI traffic.

Enable action-level observability

Completed-action logging is separate from executing actions. When the deployment’s action logger, event stream, project setting, and request metadata propagation are configured, Hermetiq can associate remote actions with queue, input-fetch, execution, output-upload, worker, and cost context.

If builds execute remotely but the Remote Execution Analytics or action timing views are empty, verify the Completed Action Log integration. Enabling it only affects newly emitted action events and does not reconstruct older runs.

Verify the integration

1. Run a small representative target with the explicit RBE configuration.
2. Confirm Bazel reports remote execution rather than silently running every action locally.
3. Open the invocation in Build History and check its command line, action outcomes, failures, and available remote-execution timing.
4. Repeat the build to exercise cache behavior, while remembering that a cache hit does not prove an action executed remotely on the second run.
5. Expand to representative tests and toolchains, then observe queue time and worker capacity under CI concurrency.

Troubleshoot remote execution