Commit Graph

4 Commits

  • ci: reuse Bazel CI startup for target-discovery queries (#19232)
    ## Why
    
    A rerun of the Windows Bazel clippy job after
    [#19161](https://github.com/openai/codex/pull/19161) had exactly the
    cache behavior we wanted in BuildBuddy: zero action-cache misses. Even
    so, the GitHub job still took a little over five minutes.
    
    The problem was that the job was paying for two separate Bazel startup
    paths:
    
    1. a `bazel query` to discover extra lint targets
    2. the real `bazel build --config=clippy ...` invocation
    
    On Windows, that query was bypassing the CI Bazel wrapper, so it did not
    reuse the same `--output_user_root`, CI config, or remote-cache setup as
    the real build. In practice that meant the rerun could still cold-start
    a separate Bazel server before the actual clippy build even began.
    
    ## What
    
    - add `.github/scripts/run-bazel-query-ci.sh` to run CI-side Bazel
    queries with the same startup and cache-related flags as the main Bazel
    command
    - switch `scripts/list-bazel-clippy-targets.sh` to use that helper for
    manual `rust_test` target discovery
    - switch `tools/argument-comment-lint/list-bazel-targets.sh` to use the
    same helper
    - simplify `.github/scripts/run-argument-comment-lint-bazel.sh` so its
    Windows-only query path also goes through the shared helper
    
    This keeps the target-discovery queries aligned with the later
    build/test invocation instead of treating them as a separate cold Bazel
    session.
    
    ## Verification
    
    - `bash -n .github/scripts/run-bazel-query-ci.sh`
    - `bash -n scripts/list-bazel-clippy-targets.sh`
    - `bash -n tools/argument-comment-lint/list-bazel-targets.sh`
    - `bash -n .github/scripts/run-argument-comment-lint-bazel.sh`
    - mocked a Windows invocation of `run-bazel-query-ci.sh` and verified it
    forwards `--output_user_root`, `--config=ci-windows`, the BuildBuddy
    auth header, and the repository cache flags
    
    ## Docs
    
    No documentation updates are needed.
  • ci: align Bazel repo cache and Windows clippy target handling (#16740)
    ## Why
    
    Bazel CI had two independent Windows issues:
    
    - The workflow saved/restored `~/.cache/bazel-repo-cache`, but
    `.bazelrc` configured `common:ci-windows
    --repository_cache=D:/a/.cache/bazel-repo-cache`, so `actions/cache` and
    Bazel could point at different directories.
    - The Windows `Bazel clippy` job passed the full explicit target list
    from `//codex-rs/...`, but some of those explicit targets are
    intentionally incompatible with `//:local_windows`.
    `run-argument-comment-lint-bazel.sh` already handles that with
    `--skip_incompatible_explicit_targets`; the clippy workflow path did
    not.
    
    I also tried switching the workflow cache path to
    `D:\a\.cache\bazel-repo-cache`, but the Windows clippy job repeatedly
    failed with `Failed to restore: Cache service responded with 400`, so
    the final change standardizes on `$HOME/.cache/bazel-repo-cache` and
    makes cache restore non-fatal.
    
    ## What Changed
    
    - Expose one repository-cache path from
    `.github/actions/setup-bazel-ci/action.yml` and export that path as
    `BAZEL_REPOSITORY_CACHE` so `run-bazel-ci.sh` passes it to Bazel after
    `--config=ci-*`.
    - Move `actions/cache/restore` out of the composite action into
    `.github/workflows/bazel.yml`, and make restore failures non-fatal
    there.
    - Save exactly the exported cache path in `.github/workflows/bazel.yml`.
    - Remove `common:ci-windows
    --repository_cache=D:/a/.cache/bazel-repo-cache` from `.bazelrc` so the
    Windows CI config no longer disagrees with the workflow cache path.
    - Pass `--skip_incompatible_explicit_targets` in the Windows `Bazel
    clippy` job so incompatible explicit targets do not fail analysis while
    the lint aspect still traverses compatible Rust dependencies.
    
    ## Verification
    
    - Parsed `.github/actions/setup-bazel-ci/action.yml` and
    `.github/workflows/bazel.yml` with Ruby's YAML loader.
    - Resubmitted PR `#16740`; CI is rerunning on the amended commit.
  • bazel: lint rust_test targets in clippy workflow (#16450)
    ## Why
    
    `cargo clippy --tests` was catching warnings in inline `#[cfg(test)]`
    code that the Bazel PR Clippy lane missed. The existing Bazel invocation
    linted `//codex-rs/...`, but that did not apply Clippy to the generated
    manual `rust_test` binaries, so warnings in targets such as
    `//codex-rs/state:state-unit-tests-bin` only surfaced as plain compile
    warnings instead of failing the lint job.
    
    ## What Changed
    
    - added `scripts/list-bazel-clippy-targets.sh` to expand the Bazel
    Clippy target set with the generated manual `rust_test` rules while
    still excluding `//codex-rs/v8-poc:all`
    - updated `.github/workflows/bazel.yml` to use that expanded target list
    in the Bazel Clippy PR job
    - updated `just bazel-clippy` to use the same target expansion locally
    - updated `.github/workflows/README.md` to document that the Bazel PR
    lint lane now covers inline `#[cfg(test)]` code
    
    ## Verification
    
    - `./scripts/list-bazel-clippy-targets.sh` includes
    `//codex-rs/state:state-unit-tests-bin`
    - `bazel build --config=clippy -- //codex-rs/state:state-unit-tests-bin`
    now fails with the same unused import in `state/src/runtime/logs.rs`
    that `cargo clippy --tests` reports