mirror of
https://github.com/openai/codex.git
synced 2026-05-14 16:22:51 +00:00
cd2760fc08
## Why #20585 moved the Windows Bazel test job to the cross-compile path, but the Windows Bazel clippy and verify-release-build jobs were still using the native Windows/MSVC-host fallback. Those two jobs became the slowest Windows PR legs, even though both are build-only signal and do not need to execute the resulting binaries. ## What Changed - Switches the Windows Bazel clippy job from `--windows-msvc-host-platform` to `--windows-cross-compile`, so clippy build actions use Linux RBE while still targeting `x86_64-pc-windows-gnullvm`. - Switches the Windows Bazel verify-release-build job to `--windows-cross-compile` as well. This job only compiles `cfg(not(debug_assertions))` Rust code under `fastbuild`, so it does not need a native Windows build host. - Keeps the old `--skip_incompatible_explicit_targets` behavior only for fork/community PRs without `BUILDBUDDY_API_KEY`, where `run-bazel-ci.sh` falls back to the local Windows MSVC-host shape. - Adds `--windows-cross-compile` support to `.github/scripts/run-bazel-query-ci.sh`, so target-discovery queries select the same `ci-windows-cross` config as the subsequent build. - Threads that option through `scripts/list-bazel-clippy-targets.sh` so the Windows clippy job discovers targets under the same platform shape as the subsequent clippy build. ## Verification Local checks: ```shell bash -n .github/scripts/run-bazel-query-ci.sh bash -n scripts/list-bazel-clippy-targets.sh ruby -e 'require "yaml"; YAML.load_file(".github/workflows/bazel.yml"); puts "ok"' RUNNER_OS=Linux ./scripts/list-bazel-clippy-targets.sh | grep -c -- '-windows-cross-bin$' RUNNER_OS=Windows ./scripts/list-bazel-clippy-targets.sh --windows-cross-compile | grep -c -- '-windows-cross-bin$' ``` The Linux target-list check reported `0` Windows-cross internal test binaries, while the Windows cross target-list check reported `47`, preserving the test-code clippy coverage shape from the existing Windows job.
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 - 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.