mirror of
https://github.com/pchuan98/codex.git
synced 2026-07-01 00:31:56 +08:00
Shijie Rao
e79e1b42b9
This is the exact same change as @bolinfest made but he could not push because of github action change permission. ## Why The `rust-release` workflow can now be run manually with `sign_macos=false` to skip macOS signing, but that path previously stopped before creating a GitHub Release. That left the unsigned macOS binaries available only as workflow-run artifacts, which are awkward to fetch from automation and cannot be retrieved with a simple unauthenticated `curl`. For the unsigned path we still should not perform the normal release side effects: no npm or Python publishing, no WinGet publishing, no `latest-alpha-cli` branch update, and no promotion to GitHub's latest release. The goal is only to make the build outputs easy to fetch from the release page. ## What changed - Allow the `release` job in `.github/workflows/rust-release.yml` to run for `workflow_dispatch` runs with `sign_macos=false`. - For unsigned runs, keep the unsigned macOS artifacts plus the normal Linux and Windows release artifacts needed for DotSlash, then create/update the GitHub Release with `make_latest: false`. - Keep the normal publish/promote paths gated to signed releases: - npm staging and publish - Python runtime publish - WinGet publish - `latest-alpha-cli` update - developer-site deploy - normal DotSlash release files - Add `.github/dotslash-unsigned-config.json`, which publishes `*-unsigned` DotSlash files that use unsigned macOS artifacts and the normal Linux/Windows artifacts. ## What I added PLEASE READ THIS!!! I added `codex-command-runner` and `codex-windows-sandbox-setup` entries to `.github/dotslash-unsigned-config.json` so that with `sign_macos=false` we would still get the dotslash files for those artifacts which are necessary for windows builds.
e79e1b42b9
ยท
2026-05-14 08:47:21 -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.ymlis the main pre-merge verification path for Rust code. It runs Bazeltestand Bazelclippyon the supported Bazel targets, including the generated Rust test binaries needed to lint inline#[cfg(test)]code.rust-ci.ymlkeeps the Cargo-native PR checks intentionally small:cargo fmt --checkcargo shearargument-comment-linton Linux, macOS, and Windowstools/argument-comment-lintpackage tests when the lint or its workflow wiring changes
Post-Merge On main
bazel.ymlalso runs on pushes tomain. This re-verifies the merged Bazel path and helps keep the BuildBuddy caches warm.rust-ci-full.ymlis the full Cargo-native verification workflow. It keeps the heavier checks off the PR path while still validating them after merge:- the full Cargo
clippymatrix - the full Cargo
nextestmatrix - release-profile Cargo builds
- cross-platform
argument-comment-lint - Linux remote-env tests
- the full Cargo
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.ymlfast enough that it usually does not dominate PR latency. - Reserve
rust-ci-full.ymlfor heavyweight Cargo-native coverage that Bazel does not replace yet.