3 Commits

• bazel: run wrapped Rust unit test shards (#18913)

  ## Why
  
  The `codex-tui` Cargo test suite was catching stale snapshot
  expectations, but the matching Bazel unit-test target was still green.
  The TUI unit target is wrapped by `workspace_root_test` so tests run
  from the repository root and Insta can resolve Cargo-like snapshot
  paths. After native Bazel sharding was enabled for that wrapped target,
  rules_rust also inserted its own sharding wrapper around the Rust test
  binary.
  
  Those two wrappers did not compose: rules_rust's sharding wrapper
  expects to run from its own runfiles cwd, while `workspace_root_test`
  deliberately changes cwd to the repo root before invoking the test. In
  that configuration, the inner wrapper could fail to enumerate the Rust
  tests and exit successfully with empty shards, so snapshot regressions
  were not being exercised by Bazel.
  
  ## What Changed
  
  - Stop enabling rules_rust's inner `experimental_enable_sharding` for
  unit-test binaries created by `codex_rust_crate`.
  - Keep the configured `shard_count` on the outer `workspace_root_test`
  target.
  - Add libtest sharding directly to `workspace_root_test_launcher.sh.tpl`
  and `workspace_root_test_launcher.bat.tpl` after the launcher has
  resolved the actual test binary and established the intended
  repository-root cwd.
  - Partition tests by a stable FNV-1a hash of each libtest test name,
  matching the stable-shard behavior we wanted without depending on the
  inner rules_rust wrapper.
  - Preserve ad-hoc local test filters by running the resolved test binary
  directly when explicit test args are supplied.
  - On Windows, run selected libtest names from the shard list in bounded
  PowerShell batches instead of concatenating every selected test into one
  `cmd.exe` command line.
  
  This PR is stacked on top of #18912, which contains only the snapshot
  expectation updates exposed once the Bazel target actually runs the TUI
  unit tests. It is also the reason #18916 becomes visible: once this
  wrapper fix makes Bazel execute the affected `codex-core` test, that
  test needs its own executable-path setup fixed.
  
  ## Verification
  
  - `cargo test -p codex-tui`
  - `bazel test //codex-rs/tui:tui-unit-tests --test_output=errors`
  - `bazel test //codex-rs/tui:all --test_output=errors`
  - `bash -n workspace_root_test_launcher.sh.tpl`
  - Exercised the Windows PowerShell batching fragment locally with a fake
  test binary and shard-list file.

  Michael Bolin · 2026-04-21 18:35:47 -07:00
  536952eeee
• bazel: enable the full Windows gnullvm CI path (#15952)

  ## Why
  
  This PR is the current, consolidated follow-up to the earlier Windows
  Bazel attempt in #11229. The goal is no longer just to get a tiny
  Windows smoke job limping along: it is to make the ordinary Bazel CI
  path usable on `windows-latest` for `x86_64-pc-windows-gnullvm`, with
  the same broad `//...` test shape that macOS and Linux already use.
  
  The earlier smoke-list version of this work was useful as a foothold,
  but it was not a good long-term landing point. Windows Bazel kept
  surfacing real issues outside that allowlist:
  
  - GitHub's Windows runner exposed runfiles-manifest bugs such as
  `FINDSTR: Cannot open D:MANIFEST`, which broke Bazel test launchers even
  when the manifest file existed.
  - `rules_rs`, `rules_rust`, LLVM extraction, and Abseil still needed
  `windows-gnullvm`-specific fixes for our hermetic toolchain.
  - the V8 path needed more work than just turning the Windows matrix
  entry back on: `rusty_v8` does not ship Windows GNU artifacts in the
  same shape we need, and Bazel's in-tree V8 build needed a set of Windows
  GNU portability fixes.
  
  Windows performance pressure also pushed this toward a full solution
  instead of a permanent smoke suite. During this investigation we hit
  targets such as `//codex-rs/shell-command:shell-command-unit-tests` that
  were much more expensive on Windows because they repeatedly spawn real
  PowerShell parsers (see #16057 for one concrete example of that
  pressure). That made it much more valuable to get the real Windows Bazel
  path working than to keep iterating on a narrowly curated subset.
  
  The net result is that this PR now aims for the same CI contract on
  Windows that we already expect elsewhere: keep standalone
  `//third_party/v8:all` out of the ordinary Bazel lane, but allow V8
  consumers under `//codex-rs/...` to build and test transitively through
  `//...`.
  
  ## What Changed
  
  ### CI and workflow wiring
  
  - re-enable the `windows-latest` / `x86_64-pc-windows-gnullvm` Bazel
  matrix entry in `.github/workflows/bazel.yml`
  - move the Windows Bazel output root to `D:\b` and enable `git config
  --global core.longpaths true` in
  `.github/actions/setup-bazel-ci/action.yml`
  - keep the ordinary Bazel target set on Windows aligned with macOS and
  Linux by running `//...` while excluding only standalone
  `//third_party/v8:all` targets from the normal lane
  
  ### Toolchain and module support for `windows-gnullvm`
  
  - patch `rules_rs` so `windows-gnullvm` is modeled as a distinct Windows
  exec/toolchain platform instead of collapsing into the generic Windows
  shape
  - patch `rules_rust` build-script environment handling so llvm-mingw
  build-script probes do not inherit unsupported `-fstack-protector*`
  flags
  - patch the LLVM module archive so it extracts cleanly on Windows and
  provides the MinGW libraries this toolchain needs
  - patch Abseil so its thread-local identity path matches the hermetic
  `windows-gnullvm` toolchain instead of taking an incompatible MinGW
  pthread path
  - keep both MSVC and GNU Windows targets in the generated Cargo metadata
  because the current V8 release-asset story still uses MSVC-shaped names
  in some places while the Bazel build targets the GNU ABI
  
  ### Windows test-launch and binary-behavior fixes
  
  - update `workspace_root_test_launcher.bat.tpl` to read the runfiles
  manifest directly instead of shelling out to `findstr`, which was the
  source of the `D:MANIFEST` failures on the GitHub Windows runner
  - thread a larger Windows GNU stack reserve through `defs.bzl` so
  Bazel-built binaries that pull in V8 behave correctly both under normal
  builds and under `bazel test`
  - remove the no-longer-needed Windows bootstrap sh-toolchain override
  from `.bazelrc`
  
  ### V8 / `rusty_v8` Windows GNU support
  
  - export and apply the new Windows GNU patch set from
  `patches/BUILD.bazel` / `MODULE.bazel`
  - patch the V8 module/rules/source layers so the in-tree V8 build can
  produce Windows GNU archives under Bazel
  - teach `third_party/v8/BUILD.bazel` to build Windows GNU static
  archives in-tree instead of aliasing them to the MSVC prebuilts
  - reuse the Linux release binding for the experimental Windows GNU path
  where `rusty_v8` does not currently publish a Windows GNU binding
  artifact
  
  ## Testing
  
  - the primary end-to-end validation for this work is the `Bazel`
  workflow plus `v8-canary`, since the hard parts are Windows-specific and
  depend on real GitHub runner behavior
  - before consolidation back onto this PR, the same net change passed the
  full Bazel matrix in [run
  23675590471](https://github.com/openai/codex/actions/runs/23675590471)
  and passed `v8-canary` in [run
  23675590453](https://github.com/openai/codex/actions/runs/23675590453)
  - those successful runs included the `windows-latest` /
  `x86_64-pc-windows-gnullvm` Bazel job with the ordinary `//...` path,
  not the earlier Windows smoke allowlist
  
  ---
  [//]: # (BEGIN SAPLING FOOTER)
  Stack created with [Sapling](https://sapling-scm.com). Best reviewed
  with [ReviewStack](https://reviewstack.dev/openai/codex/pull/15952).
  * #16067
  * __->__ #15952

  Michael Bolin · 2026-03-27 20:37:03 -07:00
  343d1af3da
• fix(ci): restore guardian coverage and bazel unit tests (#13912)

  ## Summary
  - restore the guardian review request snapshot test and its tracked
  snapshot after it was dropped from `main`
  - make Bazel Rust unit-test wrappers resolve runfiles correctly on
  manifest-only platforms like macOS and point Insta at the real workspace
  root
  - harden the shell-escalation socket-closure assertion so the musl Bazel
  test no longer depends on fd reuse behavior
  
  ## Verification
  - cargo test -p codex-core
  guardian_review_request_layout_matches_model_visible_request_snapshot
  - cargo test -p codex-shell-escalation
  - bazel test //codex-rs/exec:exec-unit-tests
  //codex-rs/shell-escalation:shell-escalation-unit-tests
  
  Supersedes #13894.
  
  ---------
  
  Co-authored-by: Ahmed Ibrahim <aibrahim@openai.com>
  Co-authored-by: viyatb-oai <viyatb@openai.com>
  Co-authored-by: Codex <noreply@openai.com>

  Charley Cunningham · 2026-03-08 12:05:19 -07:00
  7ba1fccfc1