Configure Bazel for Hermetiq

Your source of truth

Open Quickstart inside the matching Cloud or customer-managed dashboard for the project you are configuring. It provides the correct project ID, service endpoints, credential-helper mappings, and optional cache configuration. In customer-managed deployments, obtain the actual credential helper through the administrator’s approved provisioning path.

BEP configuration

The core configuration sends BEP events to Hermetiq and associates them with your project. Quickstart supplies the credential-helper host mappings used to authenticate the relevant Hermetiq endpoints; the helper itself may be a Cloud download or administrator-provided.

build:hermetiq --bes_instance_name=<PROJECT_ID>
build:hermetiq --bes_backend=<BEP_ENDPOINT>
build:hermetiq --bes_timeout=120s
build:hermetiq --bes_results_url=<RESULTS_URL>
build:hermetiq --bes_upload_mode=wait_for_upload_complete

When entries use the build:hermetiq prefix, activate them with --config=hermetiq. Quickstart can instead generate global build entries if that better fits your Bazel configuration model.

Profile configuration

These Bazel flags produce the profile data used by profile trends, critical-path analysis, parallelism analysis, and profile-derived insights:

build:hermetiq --generate_json_trace_profile
build:hermetiq --experimental_profile_include_primary_output
build:hermetiq --experimental_profile_include_target_label
build:hermetiq --noslim_profile

Build metadata

Add commit, repository, branch, role, or other stable metadata so builds can be filtered and compared in context. Quickstart documents two supported patterns:

• Pass --build_metadata values on the Bazel command line.
• Use a workspace-status script and --workspace_status_command.

Bazel does not perform shell substitution inside .bazelrc, so dynamic values belong in the command line or a script.

CI configuration

Use the same project identity in CI, but retrieve the helper or its secret values from the CI platform’s secret manager. Give each logical CI run a stable build request ID and attach repository context as build metadata.

# Store the credential helper in your CI secret manager, then materialize it for this job.
chmod 700 tools/hermetiq-credential-helper.sh

BUILD_ID="${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"
bazel test //... --config=hermetiq \
  --build_request_id="${BUILD_ID}" \
  --build_metadata=ROLE=CI \
  --build_metadata=REPO_URL=<REPOSITORY_URL> \
  --build_metadata=COMMIT_SHA=<COMMIT_SHA> \
  --build_metadata=BRANCH_NAME=<BRANCH_NAME>

• GitHub Actions commonly derives the ID from GITHUB_RUN_ID and GITHUB_RUN_ATTEMPT.
• Buildkite, Jenkins, and other systems should use their stable pipeline/build identifier plus a retry or attempt value.
• Do not print the credential helper or secret environment variables in job logs.
• Use the same --build_request_id for related build and test commands in one logical CI run.

Remote cache

Projects using Hermetiq’s remote cache receive the endpoint and instance value in Quickstart. The remote instance name must match the project identity carried by the machine credential.

build:hermetiq --remote_instance_name=<PROJECT_ID>
build:hermetiq --remote_cache=<REMOTE_CACHE_ENDPOINT>

Group related invocations

When a CI job runs multiple Bazel commands that belong to one logical build, pass the same --build_request_id to each invocation. Hermetiq can then group them into one build-level record.

# Example: use one ID for build and test invocations in the same CI run
BUILD_ID="${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}"

bazel build //... --build_request_id="${BUILD_ID}"
bazel test  //... --build_request_id="${BUILD_ID}"