mirror of
https://github.com/openai/codex.git
synced 2026-05-24 04:54:52 +00:00
64ef6cd1e4
## Why `rust-ci-full` was paying the full Cargo nextest build-and-run cost once per platform, with Windows ARM64 as the long pole. This change moves the heavy work into one reusable per-platform flow: build a nextest archive once, then replay it across four shards so the platform lane spends less time running tests serially. For Windows ARM64, the archive is cross-compiled on Windows x64 and replayed on native Windows ARM64 shards so the slow ARM64 machine is used for execution rather than compilation. ## What changed - split the `rust-ci-full` nextest matrix into five explicit per-platform reusable-workflow calls - add `.github/workflows/rust-ci-full-nextest-platform.yml` to build one archive, upload timings/helpers, replay four nextest shards, upload per-shard JUnit, and roll the shard status back up per platform - add Windows CI helpers for Dev Drive setup and MSVC ARM64 linker environment export so the Windows ARM64 archive can be produced on Windows x64 - keep the existing Cargo git CLI fetch hardening inside the reusable workflow, since caller workflow-level `env` does not flow through `workflow_call` - document the archive-backed shard shape in `.github/workflows/README.md` - raise the default nextest slow timeout to 30s so the sharded full-CI path does not treat every >15s test as stuck ## Verification - validated the archive/shard flow with live GitHub Actions runs on this PR branch - Windows ARM64 cross-compile latency on completed runs: - https://github.com/openai/codex/actions/runs/26118759651: `34m30s` lane e2e, `17m16s` archive build, `9m55s` shard phase - https://github.com/openai/codex/actions/runs/26120777976: `30m36s` lane e2e, `17m21s` archive build, `6m50s` shard phase - comparable pre-cross-compile sharded Windows ARM64 runs were `55m01s`, `50m21s`, and `46m42s`, so the completed cross-compile runs improved the lane by roughly `12m` to `24m` versus the prior range - latest corrected cross-compile run: https://github.com/openai/codex/actions/runs/26120777976 - Windows ARM64 archive built successfully on Windows x64 - native Windows ARM64 shards started immediately after the archive upload - 3/4 Windows ARM64 shards passed; the failing shard hit the same existing `code_mode` test failure seen outside this lane - downloaded failed-shard JUnit XML from the validation runs and confirmed the remaining red is from known test failures, not archive/shard wiring - no local Codex tests run per repo guidance ## Notes - this PR does not change developers.openai.com documentation
35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
# 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.yml` is the main pre-merge verification path for Rust code.
|
|
It runs Bazel `test` and Bazel `clippy` on the supported Bazel targets,
|
|
including the generated Rust test binaries needed to lint inline `#[cfg(test)]`
|
|
code.
|
|
- `rust-ci.yml` keeps the Cargo-native PR checks intentionally small:
|
|
- `cargo fmt --check`
|
|
- `cargo shear`
|
|
- `argument-comment-lint` on Linux, macOS, and Windows
|
|
- `tools/argument-comment-lint` package tests when the lint or its workflow wiring changes
|
|
|
|
## Post-Merge On `main`
|
|
|
|
- `bazel.yml` also runs on pushes to `main`.
|
|
This re-verifies the merged Bazel path and helps keep the BuildBuddy caches warm.
|
|
- `rust-ci-full.yml` is the full Cargo-native verification workflow.
|
|
It keeps the heavier checks off the PR path while still validating them after merge:
|
|
- the full Cargo `clippy` matrix
|
|
- the full Cargo `nextest` matrix 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
|
|
|
|
## 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.yml` fast enough that it usually does not dominate PR latency.
|
|
- Reserve `rust-ci-full.yml` for heavyweight Cargo-native coverage that Bazel does not replace yet.
|