mirror of
https://github.com/openai/codex.git
synced 2026-03-05 13:35:28 +03:00
bazel: enforce MODULE.bazel.lock sync with Cargo.lock (#11790)
## Why this change When Cargo dependencies change, it is easy to end up with an unexpected local diff in `MODULE.bazel.lock` after running Bazel. That creates noisy working copies and pushes lockfile fixes later in the cycle. This change addresses that pain point directly. ## What this change enforces The expected invariant is: after dependency updates, `MODULE.bazel.lock` is already in sync with Cargo resolution. In practice, running `bazel mod deps` should not mutate the lockfile in a clean state. If it does, the dependency update is incomplete. ## How this is enforced This change adds a single lockfile check script that snapshots `MODULE.bazel.lock`, runs `bazel mod deps`, and fails if the file changes. The same check is wired into local workflow commands (`just bazel-lock-update` and `just bazel-lock-check`) and into Bazel CI (Linux x86_64 job) so drift is caught early and consistently. The developer documentation is updated in `codex-rs/docs/bazel.md` and `AGENTS.md` to make the expected flow explicit. `MODULE.bazel.lock` is also refreshed in this PR to match the current Cargo dependency resolution. ## Expected developer workflow After changing `Cargo.toml` or `Cargo.lock`, run `just bazel-lock-update`, then run `just bazel-lock-check`, and include any resulting `MODULE.bazel.lock` update in the same change. ## Testing Ran `just bazel-lock-check` locally.
This commit is contained in:
5
.github/workflows/bazel.yml
vendored
5
.github/workflows/bazel.yml
vendored
@@ -65,6 +65,11 @@ jobs:
|
||||
- name: Set up Bazel
|
||||
uses: bazelbuild/setup-bazelisk@v3
|
||||
|
||||
- name: Check MODULE.bazel.lock is up to date
|
||||
if: matrix.os == 'ubuntu-24.04' && matrix.target == 'x86_64-unknown-linux-gnu'
|
||||
shell: bash
|
||||
run: ./scripts/check-module-bazel-lock.sh
|
||||
|
||||
# TODO(mbolin): Bring this back once we have caching working. Currently,
|
||||
# we never seem to get a cache hit but we still end up paying the cost of
|
||||
# uploading at the end of the build, which takes over a minute!
|
||||
|
||||
@@ -15,6 +15,10 @@ In the codex-rs folder where the rust code lives:
|
||||
- When writing tests, prefer comparing the equality of entire objects over fields one by one.
|
||||
- When making a change that adds or changes an API, ensure that the documentation in the `docs/` folder is up to date if applicable.
|
||||
- If you change `ConfigToml` or nested config types, run `just write-config-schema` to update `codex-rs/core/config.schema.json`.
|
||||
- If you change Rust dependencies (`Cargo.toml` or `Cargo.lock`), run `just bazel-lock-update` from the
|
||||
repo root to refresh `MODULE.bazel.lock`, and include that lockfile update in the same change.
|
||||
- After dependency changes, run `just bazel-lock-check` from the repo root so lockfile drift is caught
|
||||
locally before CI.
|
||||
- Do not create small helper methods that are referenced only once.
|
||||
|
||||
Run `just fmt` (in `codex-rs` directory) automatically after you have finished making Rust code changes; do not ask for approval to run it. Additionally, run the tests:
|
||||
|
||||
4
MODULE.bazel.lock
generated
4
MODULE.bazel.lock
generated
File diff suppressed because one or more lines are too long
@@ -23,7 +23,20 @@ As of 1/9/2026, this setup is still experimental as we stabilize it.
|
||||
## Evolving the setup
|
||||
|
||||
When you add or change Rust dependencies, update the Cargo.toml/Cargo.lock as normal.
|
||||
The Bazel build should automatically pick things up without any manual action needed.
|
||||
Then refresh the Bzlmod lockfile from the repo root:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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,
|
||||
|
||||
8
justfile
8
justfile
@@ -51,6 +51,14 @@ test:
|
||||
bazel-codex *args:
|
||||
bazel run //codex-rs/cli:codex --run_under="cd $PWD &&" -- "$@"
|
||||
|
||||
[no-cd]
|
||||
bazel-lock-update:
|
||||
bazel mod deps --lockfile_mode=update
|
||||
|
||||
[no-cd]
|
||||
bazel-lock-check:
|
||||
./scripts/check-module-bazel-lock.sh
|
||||
|
||||
bazel-test:
|
||||
bazel test //... --keep_going
|
||||
|
||||
|
||||
8
scripts/check-module-bazel-lock.sh
Executable file
8
scripts/check-module-bazel-lock.sh
Executable file
@@ -0,0 +1,8 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
if ! bazel mod deps --lockfile_mode=error; then
|
||||
echo "MODULE.bazel.lock is out of date."
|
||||
echo "Run 'just bazel-lock-update' and commit the updated lockfile."
|
||||
exit 1
|
||||
fi
|
||||
Reference in New Issue
Block a user