Files
codex/.github/workflows
Michael Bolin b3c4743e34 dotslash: publish Codex entrypoints from package archives
## Summary

DotSlash should resolve the same canonical package layout used by standalone installers and npm platform packages, but it should not take the size regression of downloading gzip-compressed package archives. Installers continue to use `.tar.gz` because that format is broadly available, while DotSlash can use zstd-compressed tar archives.

This updates the package archive release helper to emit both `*.tar.gz` and `*.tar.zst` package archives from the same package directory. The Codex CLI and `codex-app-server` DotSlash release config entries now match `codex-package-<target>.tar.zst` and `codex-app-server-package-<target>.tar.zst`, with paths that select `bin/codex` or `bin/codex-app-server` inside the extracted package. The Windows release compression loop also skips prebuilt `.tar.zst` archives so it does not try to recompress them as ordinary files.

The other helper outputs stay on their existing per-binary artifacts for now.

## Test plan

- `python3 -m json.tool .github/dotslash-config.json > /dev/null`
- `bash -n .github/scripts/build-codex-package-archive.sh`
- `python3 -m py_compile scripts/codex_package/cli.py`
- `ruby -e 'require "yaml"; YAML.load_file(".github/workflows/rust-release-windows.yml"); puts "ok"'`
- Ran a Python regex smoke test that checked every updated `codex` and `codex-app-server` platform entry against the `.tar.zst` archive names emitted by `.github/scripts/build-codex-package-archive.sh`.
- Ran `scripts/build_codex_package.py` with synthetic macOS entrypoint and `rg` binaries and repeated `--archive-output` values for `.tar.gz` and `.tar.zst`, verifying both archives were written.
2026-05-20 08:57:27 -07:00
..
2026-05-15 12:41:18 -07:00

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.