5 Commits

  • [codex] Fully qualify hash-pins in GitHub Actions (#21436)
    This builds on top of https://github.com/openai/codex/pull/15828 by
    ensuring that hash-pinned actions with version comments are fully
    qualified, rather than referencing floating/mutable comments like "v7".
    This makes actions management tools behave more consistently.
    
    This shouldn't break anything, since it's comment only. But if it does,
    ping ww@ 馃檪
  • ci: scope Bazel repository cache by job (#18366)
    ## Why
    
    The Bazel workflow has multiple jobs that run concurrently for the same
    target triple. In particular, the Windows `test`, `clippy`, and
    `verify-release-build` jobs could all miss and then attempt to save the
    same Bazel repository cache key:
    
    ```text
    bazel-cache-${target}-${lockhash}
    ```
    
    Because `actions/cache` entries are immutable, only one job can reserve
    that key. The others can report failures such as:
    
    ```text
    Failed to save: Unable to reserve cache with key bazel-cache-x86_64-pc-windows-gnullvm-..., another job may be creating this cache.
    ```
    
    Adding only the workflow name would not separate these jobs because they
    all run inside the same `Bazel` workflow. The key needs a job-level
    namespace as well.
    
    ## What Changed
    
    - Added a required `cache-scope` input to
    `.github/actions/prepare-bazel-ci/action.yml`.
    - Moved Bazel repository cache key construction into the shared action
    and exposed the computed key as `repository-cache-key`.
    - Exposed the exact restore result as `repository-cache-hit` so save
    steps can skip exact cache hits.
    - Updated `.github/workflows/bazel.yml` to pass `cache-scope: bazel-${{
    github.job }}` for the `test`, `clippy`, and `verify-release-build`
    jobs.
    - The scoped restore key is now the only fallback. This avoids carrying
    a temporary restore path for the old unscoped cache namespace.
    
    ## Verification
    
    - Parsed `.github/actions/prepare-bazel-ci/action.yml` and
    `.github/workflows/bazel.yml` with Ruby's YAML parser.
    - `actionlint` is not installed in this workspace, so I could not run a
    GitHub Actions semantic lint locally.
  • Add Bazel verify-release-build job (#17705)
    ## Why
    
    `main` recently needed
    [#17691](https://github.com/openai/codex/pull/17691) because code behind
    `cfg(not(debug_assertions))` was not being compiled by the Bazel PR
    workflow. Our existing CI only built the fast/debug configuration, so
    PRs could stay green while release-only Rust code still failed to
    compile. This PR adds a release-style compile check that is cheap enough
    to run on every PR.
    
    ## What Changed
    
    - Added a `verify-release-build` job to `.github/workflows/bazel.yml`.
    - Represented each supported OS once in that job's matrix: x64 Linux,
    arm64 macOS, and x64 Windows.
    - Kept the build close to fastbuild cost by using
    `--compilation_mode=fastbuild` while forcing Rust to compile with
    `-Cdebug-assertions=no`, which makes `cfg(not(debug_assertions))` true
    without also turning on release optimizations or debug-info generation.
    - Added comments in `.github/workflows/bazel.yml` and
    `scripts/list-bazel-release-targets.sh` to make the job's intent and
    target scope explicit.
    - Restored the Bazel repository cache save behavior to run after every
    non-cancelled job, matching
    [#16926](https://github.com/openai/codex/pull/16926), and removed the
    now-unused `repository-cache-hit` output from `prepare-bazel-ci`.
    - Reused the shared `prepare-bazel-ci` action from the parent PR so the
    new job does not duplicate Bazel setup boilerplate.
    
    ## Verification
    
    - Used `bazel aquery` on `//codex-rs/tui:codex-tui` to confirm the Rust
    compile still uses `opt-level=0` and `debuginfo=0` while passing
    `-Cdebug-assertions=no`.
    - Parsed `.github/workflows/bazel.yml` as YAML locally.
    - Ran `bash -n scripts/list-bazel-release-targets.sh`.
  • Refactor Bazel CI job setup (#17704)
    ## Why
    
    This stack adds a new Bazel CI lane that verifies Rust code behind
    `cfg(not(debug_assertions))`, but adding that job directly to
    `.github/workflows/bazel.yml` would duplicate the same setup in multiple
    places. Extracting the shared setup first keeps the follow-up change
    easier to review and reduces the chance that future Bazel workflow edits
    drift apart.
    
    ## What Changed
    
    - Added `.github/actions/prepare-bazel-ci/action.yml` as a composite
    action for the Bazel job bootstrap shared by multiple workflow jobs.
    - Moved the existing Bazel setup, repository-cache restore, and
    execution-log setup behind that action.
    - Updated the `test` and `clippy` jobs in `.github/workflows/bazel.yml`
    to call `prepare-bazel-ci`.
    - Exposed `repository-cache-hit` and `repository-cache-path` outputs so
    callers can keep the existing cache-save behavior without duplicating
    the restore step.
    
    ## Verification
    
    - Parsed `.github/workflows/bazel.yml` as YAML locally after rebasing
    the stack.
    - CI will exercise the refactored jobs end to end.
    
    ---
    [//]: # (BEGIN SAPLING FOOTER)
    Stack created with [Sapling](https://sapling-scm.com). Best reviewed
    with [ReviewStack](https://reviewstack.dev/openai/codex/pull/17704).
    * #17705
    * __->__ #17704