mirror of
https://github.com/openai/codex.git
synced 2026-04-30 01:16:54 +00:00
## Why Unused imports in `core/tests/suite/unified_exec.rs` in the Windows build were not caught by Bazel CI on https://github.com/openai/codex/pull/18096. I spot-checked https://github.com/openai/codex/actions/workflows/rust-ci-full.yml?query=branch%3Amain and noticed that builds were consistently red. This revealed that our Cargo builds _were_ properly catching these issues, identifying a Windows-specific coverage hole in the Bazel clippy job. The Windows Bazel clippy job uses `--skip_incompatible_explicit_targets` so it can lint a broad target set without failing immediately on targets that are genuinely incompatible with Windows. However, with the default Windows host platform, `rust_test` targets such as `//codex-rs/core:core-all-test` could be skipped before the clippy aspect reached their integration-test modules. As a result, the imports in `core/tests/suite/unified_exec.rs` were not being linted by the Windows Bazel clippy job at all. The clippy diagnostic that Windows Bazel should have surfaced was: ```text error: unused import: `codex_config::Constrained` --> core\tests\suite\unified_exec.rs:8:5 | 8 | use codex_config::Constrained; | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `-D unused-imports` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(unused_imports)]` error: unused import: `codex_protocol::permissions::FileSystemAccessMode` --> core\tests\suite\unified_exec.rs:11:5 | 11 | use codex_protocol::permissions::FileSystemAccessMode; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemPath` --> core\tests\suite\unified_exec.rs:12:5 | 12 | use codex_protocol::permissions::FileSystemPath; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemSandboxEntry` --> core\tests\suite\unified_exec.rs:13:5 | 13 | use codex_protocol::permissions::FileSystemSandboxEntry; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: unused import: `codex_protocol::permissions::FileSystemSandboxPolicy` --> core\tests\suite\unified_exec.rs:14:5 | 14 | use codex_protocol::permissions::FileSystemSandboxPolicy; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` ## What changed - Run the Windows Bazel clippy job with the MSVC host platform via `--windows-msvc-host-platform`, matching the Windows Bazel test job. This keeps `--skip_incompatible_explicit_targets` while ensuring Windows `rust_test` targets such as `//codex-rs/core:core-all-test` are still linted. - Remove the unused imports from `core/tests/suite/unified_exec.rs`. - Add `--print-failed-action-summary` to `.github/scripts/run-bazel-ci.sh` so Bazel action failures can be summarized after the build exits. ## Failure reporting Once the coverage issue was fixed, an intentionally reintroduced unused import made the Windows Bazel clippy job fail as expected. That exposed a separate usability problem: because the job keeps `--keep_going`, the top-level Bazel output could still end with: ```text ERROR: Build did NOT complete successfully FAILED: ``` without the underlying rustc/clippy diagnostic being visible in the obvious part of the GitHub Actions log. To keep `--keep_going` while making failures actionable, the wrapper now scans the captured Bazel console output for failed actions and prints the matching rustc/clippy diagnostic block. When a diagnostic block is found, it is emitted both as a GitHub `::error` annotation and as plain expanded log output, rather than being hidden in a collapsed group. ## Verification To validate the CI path, I intentionally introduced an unused import in `core/tests/suite/unified_exec.rs`. The Windows Bazel clippy job failed as expected, confirming that the integration-test module is now covered by Bazel clippy. The same failure also verified that the wrapper surfaces the matching clippy diagnostics directly in the Actions output.