mirror of
https://github.com/openai/codex.git
synced 2026-05-03 10:56:37 +00:00
cafe717dca
## Why All Bazel CI jobs are currently blocked in the `setup-bazelisk` step while trying to download Bazelisk. [`bazelbuild/setup-bazelisk`](https://github.com/bazelbuild/setup-bazelisk) is archived, and its README now recommends migrating to [`bazel-contrib/setup-bazel`](https://github.com/bazel-contrib/setup-bazel), so leaving our workflows on the archived action leaves CI exposed to exactly this sort of outage. Because `v8-canary` now consumes the shared local `setup-bazel-ci` action, that workflow also needs to trigger when the action changes. Without that follow-up, Bazel bootstrap regressions specific to the V8 canary path could be skipped by the workflow path filters. ## What Changed - Switched `.github/actions/setup-bazel-ci/action.yml` from `bazelbuild/setup-bazelisk` to `bazel-contrib/setup-bazel`, pinned to `0.19.0`. - Left `bazelisk-version` unset so GitHub-hosted runners can use their preinstalled Bazelisk instead of downloading `1.x` at job start. - Updated `.github/workflows/rusty-v8-release.yml` and `.github/workflows/v8-canary.yml` to use the shared `setup-bazel-ci` action instead of referencing `setup-bazelisk` directly. - Added `.github/actions/setup-bazel-ci/**` to the `pull_request` and `push` path filters in `.github/workflows/v8-canary.yml` so changes to the shared Bazel setup action still run the canary workflow. - Kept the existing repository-cache and Windows-specific Bazel setup logic intact. This keeps Bazel version selection anchored by `.bazelversion` while removing the failing dependency on the archived setup action. ## Verification - Searched `.github/` to confirm there are no remaining `setup-bazelisk` references. - Parsed the updated workflow and action YAML locally with Ruby's `YAML.load_file`.
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.