mirror of https://github.com/openai/codex.git synced 2026-11-06 20:20:34 +00:00

Files

T

Dmitriy Kovalenko 3f958ac2fe Run Bazel CI locally without BuildBuddy credentials (#59055 )

## What changed

- Remove automatic BuildBuddy configuration and credential forwarding from Bazel CI, release, SDK, and voice builds. Strip remote execution CI configs in the shared wrapper while retaining explicit remote configurations for local use.
- Use native Windows host tools and audio dependencies for Windows Bazel actions, forwarding the required toolchain and environment settings.
- Initialize message-board MCP servers through a per-session `OnceCell` so server startup does not hold the shared registry lock across an await.
- Expose the message-board test helper to the core Bazel package and update the runtime-auth test call for the `reauth` argument.

GitOrigin-RevId: 5d5c1f4d71fa841090dea8eec8006380981fb65b

2026-11-03 04:08:59 +00:00

5.4 KiB

Raw Blame History

Bazel in codex-rs

This repository uses Bazel to build the Rust workspace under codex-rs. Cargo remains the source of truth for crates and features, while Bazel provides hermetic builds, toolchains, and cross-platform artifacts.

As of 6/1/2026, this setup is still experimental as we stabilize it.

High-level layout

../MODULE.bazel defines Bazel dependencies and Rust toolchains.
rules_rs imports third-party crates from codex-rs/Cargo.toml and codex-rs/Cargo.lock via crate.from_cargo(...) and exposes them under @crates.
../defs.bzl provides codex_rust_crate, which wraps rust_library, rust_binary, and rust_test so Bazel targets line up with Cargo conventions. It provides a sane set of defaults that work for most first-party crates, but may need tweaks in some cases.
Each crate in codex-rs/*/BUILD.bazel typically uses codex_rust_crate and makes some adjustments if the crate needs additional compile-time or runtime data, or other customizations.

Running Bazel locally

The repository root justfile exposes the common Bazel entry points:

just bazel-test
just bazel-clippy

Ordinary local bazel and just invocations run locally. BuildBuddy cache, build event upload, downloads, and remote execution are opt-in configurations.

BuildBuddy

Codex uses BuildBuddy for a shared Bazel cache and remoted builds and tests. To use it to speed up your builds and tests you'll need to provide an API key and select a configuration.

BuildBuddy API key

If you're an OpenAI employee, log in to https://openai.buildbuddy.io and use Google sign-in.

Create a BuildBuddy API key as described in BuildBuddy's Authentication Guide, then add it to ~/.bazelrc:

# Local machine only; this file contains a BuildBuddy credential.
common --remote_header=x-buildbuddy-api-key=<your-buildbuddy-api-key>

Keeping the credential outside the workspace reduces the risk of accidentally committing it.

If you need different API keys for different projects, put the API key in %workspace%/user.bazelrc instead. The checked-in .bazelrc optionally imports that file, and .gitignore excludes it. Do not commit or share a file containing the credential.

Selecting a remote build configuration

OpenAI employees should default to the OpenAI host with remote execution unless they have a reason to choose another configuration. Add the following configuration to %workspace%/user.bazelrc:

common --config=buildbuddy-openai-rbe

OpenAI employees who don't want remote execution can use buildbuddy-openai. External users should use buildbuddy-generic-rbe or buildbuddy-generic. See below for details on these configurations.

All remote configurations

CI executes Bazel actions on its runners. The following configurations are available for explicit local use.

Invocation/config	Key Required	Cache/BES	Build exec	Test exec
`bazel ...`	No	None	Local	Local
`bazel ... --config=buildbuddy-generic`	Yes	`remote.buildbuddy.io`	Local	Local
`bazel ... --config=buildbuddy-generic-rbe`	Yes	`remote.buildbuddy.io`	Remote	Remote
`bazel ... --config=buildbuddy-openai`	Yes	`openai.buildbuddy.io`	Local	Local
`bazel ... --config=buildbuddy-openai-rbe`	Yes	`openai.buildbuddy.io`	Remote	Remote

Evolving the setup

When you add or change Rust dependencies, update the Cargo.toml/Cargo.lock as normal. Then refresh the Bzlmod lockfile from the repo root:

just bazel-lock-update

This runs bazel mod deps --lockfile_mode=update and updates MODULE.bazel.lock if needed. Commit the lockfile changes along with your Cargo lockfile update.

To verify lockfile alignment locally (the same check CI runs), use:

just bazel-lock-check

In some cases, an upstream crate may need a patch or a crate.annotation in ../MODULE.bzl to have it build in Bazel's sandbox or make it cross-compilation-friendly. If you see issues, feel free to ping zbarsky or mbolin.

When you add a new crate or binary:

Add it to the Cargo workspace as usual.
Create a BUILD.bazel that calls codex_rust_crate (see nearby crates for examples).
If a dependency needs special handling (compile/runtime data, additional binaries for integration tests, env vars, etc) you may need to adjust the parameters to codex_rust_crate to configure it. One common customization is setting test_tags = ["no-sandbox] to run the test unsandboxed. Prefer to avoid it, but it is necessary in some cases such as when the test itself uses Seatbelt (the sandbox does as well, and it cannot be nested). To limit the blast radius, consider isolating such tests to a separate crate.

If you see build issue and are not sure how to apply the proper customizations, feel free to ping zbarsky or mbolin.

References

Bazel overview: https://bazel.build/
Bzlmod (module system): https://bazel.build/external/overview
rules_rust: https://github.com/bazelbuild/rules_rust
rules_rs: https://github.com/bazelbuild/rules_rs

5.4 KiB Raw Blame History