mirror of
https://github.com/openai/codex.git
synced 2026-08-24 13:20:07 +00:00
bd5c860abe
## Why Windows Cargo and Bazel jobs spend significant time in filesystem-heavy build and cache directories. Route those directories through one CI build root so Windows can use its Dev Drive and Unix can use a stable cache root. ## What - Have `setup-ci` define `CI_BUILD_ROOT`, `CARGO_TARGET_DIR`, Bazel cache/output paths, and temp paths. - Require Windows to find or provision a verified Dev Drive instead of falling back to `C:`. - Pass the shared Bazel output base to `setup-bazel` so its explicit `output_base` does not defeat Dev Drive routing. - Point nextest, release, and V8 source-build paths at the shared environment contract. ## Benchmark results One-off cold-cache WPR/ETW traces show the explicit Bazel output-base routing removes the dominant `C:` traffic: | sample | `C:\_bazel` | summed `C:` traffic | traced test step | |---|---:|---:|---:| | shard 1 before | 62.2 GiB | 85.2 GiB | 16m22s | | shard 1 updated | 0 | 16.5 GiB | 12m05s | | shard 3 before | 67.2 GiB | 84.6 GiB | 16m48s | | shard 3 updated | 0 | 13.5 GiB | 11m08s | For a cold x64 V8 source build, the retained build-tail sample showed `D:\cargo-target` at ~1.29 GiB while measured `C:` roots totaled ~0.45 GiB (`C:\Users` ~0.33 GiB, `C:\Program Files` ~0.06 GiB, `C:\Windows` ~0.03 GiB). The full cold build took 2h20m36s. The Bazel timing improvement is directional because both refreshed shards failed tests. The V8 trace is a bounded build-tail sample, not the full build. All final samples had zero lost ETW events; VHDX traffic was excluded from the optimization ranking. Runs: [baseline Bazel](https://github.com/openai/codex/actions/runs/28911908527), [updated Bazel](https://github.com/openai/codex/actions/runs/28917133701), [V8 build tail](https://github.com/openai/codex/actions/runs/28933626678). ## Manual validation - Ran `just fmt`. - Ran `just test-github-scripts` (35 tests). - Parsed GitHub Actions YAML with `yq`. - Ran `git diff --check`. ## Stack - [#31332](https://github.com/openai/codex/pull/31332) — parameterize Cargo target paths - [#31356](https://github.com/openai/codex/pull/31356) — Windows 2025 runner bump - [#31357](https://github.com/openai/codex/pull/31357) — Dev Drive I/O routing
Workflow Strategy
The workflows in this directory are split so that pull requests get fast, review-friendly signal while main still gets the full cross-platform verification pass.
Pull Requests
bazel.ymlis the main pre-merge verification path for Rust code. It runs Bazeltestand Bazelclippyon the supported Bazel targets, including the generated Rust test binaries needed to lint inline#[cfg(test)]code.rust-ci.ymlkeeps the Cargo-native PR checks intentionally small:cargo fmt --checkcargo shearargument-comment-linton Linux, macOS, and Windowstools/argument-comment-lintpackage tests when the lint or its workflow wiring changes
Post-Merge On main
bazel.ymlalso runs on pushes tomain. This re-verifies the merged Bazel path and helps keep the BuildBuddy caches warm.rust-ci-full.ymlis the full Cargo-native verification workflow. It keeps the heavier checks off the PR path while still validating them after merge:- the full Cargo
clippymatrix - the full Cargo
nextestmatrix via per-platform archive-backed shards - Windows ARM64 nextest archives cross-compiled on Windows x64, then replayed on native Windows ARM64 shards
- release-profile Cargo builds
- cross-platform
argument-comment-lint - Linux remote-env tests
- the full Cargo
Rule Of Thumb
- If a build/test/clippy check can be expressed in Bazel, prefer putting the PR-time version in
bazel.yml. - Keep
rust-ci.ymlfast enough that it usually does not dominate PR latency. - Reserve
rust-ci-full.ymlfor heavyweight Cargo-native coverage that Bazel does not replace yet.