mirror of
https://github.com/openai/codex.git
synced 2026-04-29 17:06:51 +00:00
## Why `argument-comment-lint` had become a PR bottleneck because the repo-wide lane was still effectively running a `cargo dylint`-style flow across the workspace instead of reusing Bazel's Rust dependency graph. That kept the lint enforced, but it threw away the main benefit of moving this job under Bazel in the first place: metadata reuse and cacheable per-target analysis in the same shape as Clippy. This change moves the repo-wide lint onto a native Bazel Rust aspect so Linux and macOS can lint `codex-rs` without rebuilding the world crate-by-crate through the wrapper path. ## What Changed - add a nightly Rust toolchain with `rustc-dev` for Bazel and a dedicated crate-universe repo for `tools/argument-comment-lint` - add `tools/argument-comment-lint/driver.rs` and `tools/argument-comment-lint/lint_aspect.bzl` so Bazel can run the lint as a custom `rustc_driver` - switch repo-wide `just argument-comment-lint` and the Linux/macOS `rust-ci` lanes to `bazel build --config=argument-comment-lint //codex-rs/...` - keep the Python/DotSlash wrappers as the package-scoped fallback path and as the current Windows CI path - gate the Dylint entrypoint behind a `bazel_native` feature so the Bazel-native library avoids the `dylint_*` packaging stack - update the aspect runtime environment so the driver can locate `rustc_driver` correctly under remote execution - keep the dedicated `tools/argument-comment-lint` package tests and wrapper unit tests in CI so the source and packaged entrypoints remain covered ## Verification - `python3 -m unittest discover -s tools/argument-comment-lint -p 'test_*.py'` - `cargo test` in `tools/argument-comment-lint` - `bazel build //tools/argument-comment-lint:argument-comment-lint-driver --@rules_rust//rust/toolchain/channel=nightly` - `bazel build --config=argument-comment-lint //codex-rs/utils/path-utils:all` - `bazel build --config=argument-comment-lint //codex-rs/rollout:rollout` --- [//]: # (BEGIN SAPLING FOOTER) Stack created with [Sapling](https://sapling-scm.com). Best reviewed with [ReviewStack](https://reviewstack.dev/openai/codex/pull/16106). * #16120 * __->__ #16106
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.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
The PR workflow still keeps the Linux lint lane on the default-targets-only invocation for now, but the released linter runs on Linux, macOS, and Windows before merge.
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.