Changelog

bb agent fix reproduces a failure from a previous invocation and fixes it by editing the current working tree.

The agent reruns the invocation's original Bazel command to reproduce the failure, inspects the failure output and relevant source code, applies a minimal fix, and reruns the command to verify the fix is valid.

When run locally, the changes are applied to the current working tree. When run remotely, the diffset is uploaded to the 'Artifacts' tab of the remote agent fix run. It can be fetched from the invocation using the GetInvocation API and applied to a local workspace using git apply <DIFF_FILE>.

Run it from the workspace that produced the failure, with an invocation ID or URL:

# Fix every failing target in the invocation.
bb agent fix <INVOCATION_ID>

# Fix only a single failing target, or only the test cases matching a filter.
bb agent fix <INVOCATION_ID> //foo:bar_test --test_filter=TestBaz

See the documentation for more details.

You can now use the bb CLI to analyze a Bazel timing profile with an AI coding agent using bb agent analyze-profile.

The command downloads the timing profile for an invocation and returns a detailed report with actionable recommendations for speeding up the build.

The command accepts an invocation ID or URL:

bb agent analyze-profile <INVOCATION_ID>
bb agent analyze-profile https://app.buildbuddy.io/invocation/<INVOCATION_ID>

The command supports interpreting the timing profile with --agent=codex or --agent=claude. If available, it uses your locally authenticated Claude Code or Codex subscription. Otherwise you can set the environment variable ANTHROPIC_API_KEY or CODEX_API_KEY to authorize API requests. You can also specify --model and --effort to control the agent's behavior.

bb agent analyze-profile --agent=codex --model=gpt-5.4 --effort=high <INVOCATION_ID>

See the bb agent analyze-profile documentation for more details.

You can now use the bb CLI to detect non-deterministic builds using the bb detect nondeterminism command.

The command runs a Bazel command twice with caching disabled, then compares the two compact execution logs with bb explain. Spans whose outputs differ between the two runs are reported as non-deterministic.

# By default, the command runs "build //...".
bb detect nondeterminism

# You can pass any Bazel command to run.
bb detect nondeterminism --bazel_command='build //foo:bar --config=linux'

Sending notifications​

To email all BuildBuddy org admins when non-determinism is detected, add --notify_email. To post a notification to a Slack channel, add --notify_slack=<SECRET_NAME>, where <SECRET_NAME> is the name of a BuildBuddy secret holding a Slack webhook URL.

Sending notifications requires an API key with the notification capability. Set it via the BB_NOTIFY_API_KEY environment variable:

BB_NOTIFY_API_KEY=<API_KEY> bb detect nondeterminism --notify_email

Running on a schedule​

To schedule a nightly nondeterminism check to catch regressions, you can configure a scheduled Workflow in your buildbuddy.yaml:

actions:
  - name: Nondeterminism check
    triggers:
      schedule:
        crons:
          - "0 8 * * *" # 8:00 AM UTC every day
    steps:
      - run: bb detect nondeterminism --notify_email --notify_slack=SLACK_WEBHOOK_SECRET_NAME
    platform_properties:
      # Caching is disabled for this check anyway, so recycling adds little.
      recycle-runner: false

bb explain shows a structural diff of two compact execution logs. It helps answer the common questions: "Why did Bazel re-execute that action?" and "What changed between these builds?"

It can highlight non-hermetic outputs and differences in inputs, environment variables, and arguments.

It works with your last two builds automatically, or you can point it at any invocation IDs:

bb explain
bb explain --old <OLD_INVOCATION_ID> --new <NEW_INVOCATION_ID>

You can download the bb CLI here. More details in Fabian's BazelCon talk.

The drilldown view displays heatmaps of build and execution metrics over time. It can help isolate why a subset of builds is slower or failing more often.

You can select a region of outliers on the heatmap, and Drilldowns will compare that selection against the baseline across dimensions like branch, pattern, and tag.

This makes it easier to spot common characteristics of problematic builds.

Available on the sidebar under Drilldowns.

The compare invocations view allows you to diff two invocations side-by-side.

It can help debug why two builds produced different results by showing exactly what changed: different flags, startup options, cache/remote execution settings, status, and more.

To compare invocations:

1. From one invocation link, select Compare -> Select for comparison in the top right corner.
2. From another invocation link, select Compare -> Compare with selected.
3. For even more details on differences between the two invocations, click the Run bb explain button on the compare invocations page.

The compare actions view allows you to diff two actions side-by-side.

This can help pinpoint why two seemingly similar actions produced different results or didn't result in a cache hit.

To compare actions:

1. From an invocation link, you can find the desired action either in the Cache or Remote Execution tabs.
2. Click through to the Action Details view.
3. Click Compare -> Select for comparison in the top right corner.
4. Find the other action you want to compare it against.
5. Click Compare -> Compare with selected in the top right corner of the second action.