[please leave open, collaborating with mbolin] WIP: bazelification#8832
Closed
dzbarsky wants to merge 13 commits intoopenai:mainfrom
Closed
[please leave open, collaborating with mbolin] WIP: bazelification#8832dzbarsky wants to merge 13 commits intoopenai:mainfrom
dzbarsky wants to merge 13 commits intoopenai:mainfrom
Conversation
bolinfest
reviewed
Jan 7, 2026
dzbarsky
force-pushed
the
zbarsky/bazel
branch
from
5c913b3 to
2da46d4
Compare
bolinfest
reviewed
Jan 7, 2026
| ], | ||
| exec_properties = { | ||
| # Need git in the image... | ||
| "container-image": "docker://ghcr.io/cicirello/pyaction:latest", |
Collaborator
There was a problem hiding this comment.
For files such as:
In the Dockerfile that we create for our own image, we should:
- Add the
dotslashbinary. - Run
dotslash -- fetch codex-rs/exec-server/tests/suite/bashas part of building the container so it is in theDOTSLASH_CACHEwhen a job runs.
bolinfest
added a commit
that referenced
this pull request
Jan 7, 2026
) The Bazelification work in-flight over at #8832 needs this fix so that Bazel can find the path to the DotSlash file for `bash`. With this change, the following almost works: ``` bazel test --test_output=errors //codex-rs/exec-server:exec-server-all-test ``` That is, now the `list_tools` test passes, but `accept_elicitation_for_prompt_rule` still fails because it runs Seatbelt itself, so it needs to be run outside Bazel's local sandboxing.
dzbarsky
force-pushed
the
zbarsky/bazel
branch
from
75e44e8 to
019e438
Compare
dzbarsky
force-pushed
the
zbarsky/bazel
branch
from
019e438 to
73c296d
Compare
pap-openai
pushed a commit
that referenced
this pull request
Jan 9, 2026
) The Bazelification work in-flight over at #8832 needs this fix so that Bazel can find the path to the DotSlash file for `bash`. With this change, the following almost works: ``` bazel test --test_output=errors //codex-rs/exec-server:exec-server-all-test ``` That is, now the `list_tools` test passes, but `accept_elicitation_for_prompt_rule` still fails because it runs Seatbelt itself, so it needs to be run outside Bazel's local sandboxing.
bolinfest
added a commit
that referenced
this pull request
Jan 9, 2026
This PR configures Codex CLI so it can be built with [Bazel](https://bazel.build) in addition to Cargo. The `.bazelrc` includes configuration so that remote builds can be done using [BuildBuddy](https://www.buildbuddy.io). If you are familiar with Bazel, things should work as you expect, e.g., run `bazel test //... --keep-going` to run all the tests in the repo, but we have also added some new aliases in the `justfile` for convenience: - `just bazel-test` to run tests locally - `just bazel-remote-test` to run tests remotely (currently, the remote build is for x86_64 Linux regardless of your host platform). Note we are currently seeing the following test failures in the remote build, so we still need to figure out what is happening here: ``` failures: suite::compact::manual_compact_twice_preserves_latest_user_messages suite::compact_resume_fork::compact_resume_after_second_compaction_preserves_history suite::compact_resume_fork::compact_resume_and_fork_preserve_model_history_view ``` - `just build-for-release` to build release binaries for all platforms/architectures remotely To setup remote execution: - [Create a buildbuddy account](https://app.buildbuddy.io/) (OpenAI employees should also request org access at https://openai.buildbuddy.io/join/ with their `@openai.com` email address.) - [Copy your API key](https://app.buildbuddy.io/docs/setup/) to `~/.bazelrc` (add the line `build --remote_header=x-buildbuddy-api-key=YOUR_KEY`) - Use `--config=remote` in your `bazel` invocations (or add `common --config=remote` to your `~/.bazelrc`, or use the `just` commands) ## CI In terms of CI, this PR introduces `.github/workflows/bazel.yml`, which uses Bazel to run the tests _locally_ on Mac and Linux GitHub runners (we are working on supporting Windows, but that is not ready yet). Note that the failures we are seeing in `just bazel-remote-test` do not occur on these GitHub CI jobs, so everything in `.github/workflows/bazel.yml` is green right now. The `bazel.yml` uses extra config in `.github/workflows/ci.bazelrc` so that macOS CI jobs build _remotely_ on Linux hosts (using the `docker://docker.io/mbolin491/codex-bazel` Docker image declared in the root `BUILD.bazel`) using cross-compilation to build the macOS artifacts. Then these artifacts are downloaded locally to GitHub's macOS runner so the tests can be executed natively. This is the relevant config that enables this: ``` common:macos --config=remote common:macos --strategy=remote common:macos --strategy=TestRunner=darwin-sandbox,local ``` Because of the remote caching benefits we get from BuildBuddy, these new CI jobs can be extremely fast! For example, consider these two jobs that ran all the tests on Linux x86_64: - Bazel 1m37s https://github.com/openai/codex/actions/runs/20861063212/job/59940545209?pr=8875 - Cargo 9m20s https://github.com/openai/codex/actions/runs/20861063192/job/59940559592?pr=8875 For now, we will continue to run both the Bazel and Cargo jobs for PRs, but once we add support for Windows and running Clippy, we should be able to cutover to using Bazel exclusively for PRs, which should still speed things up considerably. We will probably continue to run the Cargo jobs post-merge for commits that land on `main` as a sanity check. Release builds will also continue to be done by Cargo for now. Earlier attempt at this PR: #8832 Earlier attempt to add support for Buck2, now abandoned: #8504 --------- Co-authored-by: David Zbarsky <dzbarsky@gmail.com> Co-authored-by: Michael Bolin <mbolin@openai.com>
khongtrunght
pushed a commit
to khongtrunght/codex
that referenced
this pull request
Jan 16, 2026
…enai#8861) The Bazelification work in-flight over at openai#8832 needs this fix so that Bazel can find the path to the DotSlash file for `bash`. With this change, the following almost works: ``` bazel test --test_output=errors //codex-rs/exec-server:exec-server-all-test ``` That is, now the `list_tools` test passes, but `accept_elicitation_for_prompt_rule` still fails because it runs Seatbelt itself, so it needs to be run outside Bazel's local sandboxing. (cherry picked from commit 54b290e)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This sets up remote builds + tests. To execute them:
bazel test //... --config=remote --platforms=//:rbe -k