Files
codex/.github/workflows
T
Tamir Duberstein 5c48e31954 [codex] parallelize Windows compression (#27855)
Each Windows packaging job creates three compressed forms of five
binaries in sequence. This takes roughly two minutes and is on the
release critical path.

Use two xargs workers to compress independent binaries concurrently.
The workers only read the raw executables and write per-binary archive
names. The Codex zip can safely read the helper executables while their
own archives are generated.

On a 16-vCPU AMD EPYC 9V74 Windows x64 release runner, alternating
trials against artifacts from release run 27391514823 measured:

  serial:   121 s, 123 s, 121 s
  parallel:  73 s,  73 s,  74 s

This saves 47 to 50 seconds in the x64 packaging lane, reducing the
observed release critical path by about 48 seconds when x64 remains the
limiting lane.

https://github.com/openai/codex/actions/runs/27401905938
5c48e31954 ยท 2026-06-12 16:26:39 -07:00
History
..

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.