5 Commits

• test: run app-server integration tests under Wine (#29788)

  ## Why
  
  Made a mistake when carving #29746 out of my local changes and the test
  was missing from the build graph. Oops!
  
  ## What
  
  Enable the app-server Wine exec test target. Remove the `manual` tag
  from generated Wine-exec test variants so wildcard Bazel test
  invocations select them. Refactor the smoke test to ensure it passes
  with current Windows support.

  Adam Perry @ OpenAI · 2026-06-24 05:23:29 +00:00
  b17f30eb2a
• [codex] Add hermetic Wine exec-server test (#27937)

  ## Why
  
  We want to make it possible for an app-server orchestrator on one OS to
  control an exec-server on another host running a different OS. In
  practice this kinda already works if you get lucky and the two hosts
  have the same path format, but we mangle quite a lot of operations if
  either end is Windows.
  
  This test starts exercising that interaction, although right now the
  initial bootstrap fails. Future changes will expand the test's
  assertions to match improved support.
  
  ## What
  
  Stacked on #27964. This adds a small Windows exec-server fixture and a
  Linux protocol smoke test using the reusable Wine harness, covering
  Windows environment discovery, non-TTY `cmd.exe` execution, output, exit
  status, and working directory.
  
  Once we've got the full codex binary cross-building under Bazel we could
  consider moving to the real binary instead of the stripped down
  exec-server-only binary used here.

  Adam Perry @ OpenAI · 2026-06-12 20:20:23 -07:00
  9d938a46d9
• ci: cross-compile Windows Bazel tests (#20585)

  ## Status
  
  This is the Bazel PR-CI cross-compilation follow-up to #20485. It is
  intentionally split from the Cargo/cargo-xwin release-build PoC so
  #20485 can stay as the historical release-build exploration. The
  unrelated async-utils test cleanup has been moved to #20686, so this PR
  is focused on the Windows Bazel CI path.
  
  The intended tradeoff is now explicit in `.github/workflows/bazel.yml`:
  pull requests get the fast Windows cross-compiled Bazel test leg, while
  post-merge pushes to `main` run both that fast cross leg and a fully
  native Windows Bazel test leg. The native main-only job keeps full
  V8/code-mode coverage and gets a 40-minute timeout because it is less
  latency-sensitive than PR CI. All other Bazel jobs remain at 30 minutes.
  
  ## Why
  
  Windows Bazel PR CI currently does the expensive part of the build on
  Windows. A native Windows Bazel test job on `main` completed in about
  28m12s, leaving very little headroom under the 30-minute job timeout and
  making Windows the slowest PR signal.
  
  #20485 showed that Windows cross-compilation can be materially faster
  for Cargo release builds, but PR CI needs Bazel because Bazel owns our
  test sharding, flaky-test retries, and integration-test layout. This PR
  applies the same high-level shape we already use for macOS Bazel CI:
  compile with remote Linux execution, then run platform-specific tests on
  the platform runner.
  
  The compromise is deliberately signal-aware: code-mode/V8 changes are
  rare enough that PR CI can accept losing the direct V8/code-mode
  smoke-test signal temporarily, while `main` still runs the native
  Windows job post-merge to catch that class of regression. A follow-up PR
  should investigate making the cross-built Windows gnullvm V8 archive
  pass the direct V8/code-mode tests so this tradeoff can eventually go
  away.
  
  ## What Changed
  
  - Adds a `ci-windows-cross` Bazel config that targets
  `x86_64-pc-windows-gnullvm`, uses Linux RBE for build actions, and keeps
  `TestRunner` actions local on the Windows runner.
  - Adds explicit Windows platform definitions for
  `windows_x86_64_gnullvm`, `windows_x86_64_msvc`, and a bridge toolchain
  that lets gnullvm test targets execute under the Windows MSVC host
  platform.
  - Updates the Windows Bazel PR test leg to opt into the cross-compile
  path via `--windows-cross-compile` and `--remote-download-toplevel`.
  - Adds a `test-windows-native-main` job that runs only for `push` events
  on `refs/heads/main`, uses the native Windows Bazel path, includes
  V8/code-mode smoke tests, and has `timeout-minutes: 40`.
  - Keeps fork/community PRs without `BUILDBUDDY_API_KEY` on the previous
  local Windows MSVC-host fallback, including
  `--host_platform=//:local_windows_msvc` and `--jobs=8`.
  - Preserves the existing integration-test shape on non-gnullvm
  platforms, while generating Windows-cross wrapper targets only for
  `windows_gnullvm`.
  - Resolves `CARGO_BIN_EXE_*` values from runfiles at test runtime,
  avoiding hard-coded Cargo paths and duplicate test runfiles.
  - Extends the V8 Bazel patches enough for the
  `x86_64-pc-windows-gnullvm` target and Linux remote execution path.
  - Makes the Windows sandbox test cwd derive from `INSTA_WORKSPACE_ROOT`
  at runtime when Bazel provides it, because cross-compiled binaries may
  contain Linux compile-time paths.
  - Keeps the direct V8/code-mode unit smoke tests out of the Windows
  cross PR path for now while native Windows CI continues to cover them
  post-merge.
  
  ## Command Shape
  
  The fast Windows PR test leg invokes the normal Bazel CI wrapper like
  this:
  
  ```shell
  ./.github/scripts/run-bazel-ci.sh \
    --print-failed-action-summary \
    --print-failed-test-logs \
    --windows-cross-compile \
    --remote-download-toplevel \
    -- \
    test \
    --test_tag_filters=-argument-comment-lint \
    --test_verbose_timeout_warnings \
    --build_metadata=COMMIT_SHA=${GITHUB_SHA} \
    -- \
    //... \
    -//third_party/v8:all \
    -//codex-rs/code-mode:code-mode-unit-tests \
    -//codex-rs/v8-poc:v8-poc-unit-tests
  ```
  
  With the BuildBuddy secret available on Windows, the wrapper selects
  `--config=ci-windows-cross` and appends the important Windows-cross
  overrides after rc expansion:
  
  ```shell
  --host_platform=//:rbe
  --shell_executable=/bin/bash
  --action_env=PATH=/usr/bin:/bin
  --host_action_env=PATH=/usr/bin:/bin
  --test_env=PATH=${CODEX_BAZEL_WINDOWS_PATH}
  ```
  
  The native post-merge Windows job intentionally omits
  `--windows-cross-compile` and does not exclude the V8/code-mode unit
  targets:
  
  ```shell
  ./.github/scripts/run-bazel-ci.sh \
    --print-failed-action-summary \
    --print-failed-test-logs \
    -- \
    test \
    --test_tag_filters=-argument-comment-lint \
    --test_verbose_timeout_warnings \
    --build_metadata=COMMIT_SHA=${GITHUB_SHA} \
    --build_metadata=TAG_windows_native_main=true \
    -- \
    //... \
    -//third_party/v8:all
  ```
  
  ## Research Notes
  
  The existing macOS Bazel CI config already uses the model we want here:
  build actions run remotely with `--strategy=remote`, but `TestRunner`
  actions execute on the macOS runner. This PR mirrors that pattern for
  Windows with `--strategy=TestRunner=local`.
  
  The important Bazel detail is that `rules_rs` is already targeting
  `x86_64-pc-windows-gnullvm` for Windows Bazel PR tests. This PR changes
  where the build actions execute; it does not switch the Bazel PR test
  target to Cargo, `cargo-nextest`, or the MSVC release target.
  
  Cargo release builds differ from this Bazel path for V8: the normal
  Windows Cargo release target is MSVC, and `rusty_v8` publishes prebuilt
  Windows MSVC `.lib.gz` archives. The Bazel PR path targets
  `windows-gnullvm`; `rusty_v8` does not publish a prebuilt Windows
  GNU/gnullvm archive, so this PR builds that archive in-tree. That
  Linux-RBE-built gnullvm archive currently crashes in direct V8/code-mode
  smoke tests, which is why the workflow keeps native Windows coverage on
  `main`.
  
  The less obvious Bazel detail is test wrapper selection. Bazel chooses
  the Windows test wrapper (`tw.exe`) from the test action execution
  platform, not merely from the Rust target triple. The outer
  `workspace_root_test` therefore declares the default test toolchain and
  uses the bridge toolchain above so the test action executes on Windows
  while its inner Rust binary is built for gnullvm.
  
  The V8 investigation exposed a Windows-client gotcha: even when an
  action execution platform is Linux RBE, Bazel can still derive the
  genrule shell path from the Windows client. That produced remote
  commands trying to run `C:\Program Files\Git\usr\bin\bash.exe` on Linux
  workers. The wrapper now passes `--shell_executable=/bin/bash` with
  `--host_platform=//:rbe` for the Windows cross path.
  
  The same Windows-client/Linux-RBE boundary also affected
  `third_party/v8:binding_cc`: a multiline genrule command can carry CRLF
  line endings into Linux remote bash, which failed as `$'\r'`. That
  genrule now keeps the `sed` command on one physical shell line while
  using an explicit Starlark join so the shell arguments stay readable.
  
  ## Verification
  
  Local checks included:
  
  ```shell
  bash -n .github/scripts/run-bazel-ci.sh
  bash -n workspace_root_test_launcher.sh.tpl
  ruby -e "require %q{yaml}; YAML.load_file(%q{.github/workflows/bazel.yml}); puts %q{ok}"
  RUNNER_OS=Linux ./scripts/list-bazel-clippy-targets.sh
  RUNNER_OS=Windows ./scripts/list-bazel-clippy-targets.sh
  RUNNER_OS=Linux ./tools/argument-comment-lint/list-bazel-targets.sh
  RUNNER_OS=Windows ./tools/argument-comment-lint/list-bazel-targets.sh
  ```
  
  The Linux clippy and argument-comment target lists contain zero
  `*-windows-cross-bin` labels, while the Windows lists still include 47
  Windows-cross internal test binaries.
  
  CI evidence:
  
  - Baseline native Windows Bazel test on `main`: success in about 28m12s,
  https://github.com/openai/codex/actions/runs/25206257208/job/73907325959
  - Green Windows-cross Bazel run on the split PR before adding the
  main-only native leg: Windows test 9m16s, Windows release verify 5m10s,
  Windows clippy 4m43s,
  https://github.com/openai/codex/actions/runs/25231890068
  - The latest SHA adds the explicit PR-vs-main tradeoff in `bazel.yml`;
  CI is rerunning on that focused diff.
  
  ## Follow-Up
  
  A subsequent PR should investigate making a cross-built Windows binary
  work with V8/code-mode enabled. Likely options are either making the
  Linux-RBE-built `windows-gnullvm` V8 archive correct at runtime, or
  evaluating whether a Bazel MSVC target/toolchain can reuse the same
  prebuilt MSVC `rusty_v8` archive shape that Cargo release builds already
  use.

  Michael Bolin · 2026-05-01 15:55:28 -07:00
  466798aa83
• 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.

  Michael Bolin · 2026-04-23 23:26:17 -07:00
  b68366718b
• fix: close Bazel argument-comment-lint CI gaps (#16253)

  ## Why
  
  The Bazel-backed `argument-comment-lint` CI path had two gaps:
  
  - Bazel wildcard target expansion skipped inline unit-test crates from
  `src/` modules because the generated `*-unit-tests-bin` `rust_test`
  targets are tagged `manual`.
  - `argument-comment-mismatch` was still only a warning in the Bazel and
  packaged-wrapper entrypoints, so a typoed `/*param_name*/` comment could
  still pass CI even when the lint detected it.
  
  That left CI blind to real linux-sandbox examples, including the missing
  `/*local_port*/` comment in
  `codex-rs/linux-sandbox/src/proxy_routing.rs` and typoed argument
  comments in `codex-rs/linux-sandbox/src/landlock.rs`.
  
  ## What Changed
  
  - Added `tools/argument-comment-lint/list-bazel-targets.sh` so Bazel
  lint runs cover `//codex-rs/...` plus the manual `rust_test`
  `*-unit-tests-bin` targets.
  - Updated `just argument-comment-lint`, `rust-ci.yml`, and
  `rust-ci-full.yml` to use that helper.
  - Promoted both `argument-comment-mismatch` and
  `uncommented-anonymous-literal-argument` to errors in every strict
  entrypoint:
    - `tools/argument-comment-lint/lint_aspect.bzl`
    - `tools/argument-comment-lint/src/bin/argument-comment-lint.rs`
    - `tools/argument-comment-lint/wrapper_common.py`
  - Added wrapper/bin coverage for the stricter lint flags and documented
  the behavior in `tools/argument-comment-lint/README.md`.
  - Fixed the now-covered callsites in
  `codex-rs/linux-sandbox/src/proxy_routing.rs`,
  `codex-rs/linux-sandbox/src/landlock.rs`, and
  `codex-rs/core/src/shell_snapshot_tests.rs`.
  
  This keeps the Bazel target expansion narrow while making the Bazel and
  prebuilt-linter paths enforce the same strict lint set.
  
  ## Verification
  
  - `python3 -m unittest discover -s tools/argument-comment-lint -p
  'test_*.py'`
  - `cargo +nightly-2025-09-18 test --manifest-path
  tools/argument-comment-lint/Cargo.toml`
  - `just argument-comment-lint`

  Michael Bolin · 2026-03-30 11:59:50 -07:00
  9313c49e4c