11 Commits

• [codex] group blocking and postmerge CI workflows (#30146)

  ## Why
  
  It's hard to change the set of required jobs when they're managed in the
  GitHub UI, and when each workflow is responsible for choosing it's own
  scheduling it's easy to end up with skew between what we enforce on PRs
  vs. on main.
  
  ## What
  
  - add a `blocking-ci` caller workflow, triggered by pull requests and
  pushes to `main`, for Bazel, blob size, cargo-deny, Codespell,
  `repo-checks`, rust CI, and SDK CI
  - add an `always()` terminal job named `CI required` that fails unless
  every called workflow succeeds
  - add a `postmerge-ci` caller workflow for `rust-ci-full` and
  `v8-canary`, with a terminal `Postmerge CI results` job
  - centralize V8 relevance detection in `v8_canary_changes.py`; unrelated
  PR and postmerge runs execute metadata only and skip the expensive build
  matrices
  - leave `v8-canary` outside the blocking gate and leave the external
  `cla` check independent
  
  ## Rollout
  
  A repository admin must replace the existing required GitHub Actions
  contexts with `CI required` in the main-branch ruleset. Retain `cla` as
  a separate required check. Until that change is coordinated, this PR
  cannot satisfy the old standalone check names. In-flight PRs will need
  to be rebased after this lands.

  Adam Perry @ OpenAI · 2026-06-26 15:07:05 -07:00
  1168254bd9
• ci: fail jobs that dirty the worktree (#29720)

  ## Why
  
  CI jobs should not silently leave tracked changes or untracked files in
  the repository worktree.
  
  ## What
  
  - Add a shared final worktree-cleanliness action to 19 checkout-bearing
  PR and main CI jobs.
  - Ignore the intentional SDK scratch directory and nested V8 checkout.
  - Pin Bazelisk in shared CI setup so `.bazelversion` remains
  authoritative, avoiding `MODULE.bazel.lock` deltas on Windows runners.
  - Leave `rust-ci-full` and release-only workflows unchanged.
  - Update `AGENTS.md` to discourage review bots from asking for
  `MODULE.bazel.lock` changes.

  Adam Perry @ OpenAI · 2026-06-24 11:06:35 -07:00
  93c79046d6
• [codex] Use git CLI for Cargo fetches across Rust workflows (#25775)

  ## Why
  Cargo's libgit2 transport has intermittently failed while fetching git
  dependencies with nested submodules.
  [#25644](https://github.com/openai/codex/pull/25644) applied
  `CARGO_NET_GIT_FETCH_WITH_CLI=true` to the main Rust release build after
  macOS SecureTransport/libgit2 failures while cloning `libwebrtc`'s
  nested `libyuv` submodule. Similar flakes can affect other Cargo-bearing
  Rust jobs.
  
  ## What changed
  Configure `CARGO_NET_GIT_FETCH_WITH_CLI=true` at workflow scope for the
  remaining Cargo-bearing Rust workflows:
  
  - fast Rust CI and `cargo-deny`
  - reusable Windows and argument-comment-lint release workflows
  - `rusty-v8-release` and `v8-canary` Cargo builds and smoke tests
  
  The full Rust CI, reusable nextest workflow, and primary Rust release
  build already had the override. Bazel-only workflows are unchanged
  because they use a different dependency fetch path.
  
  ## Validation
  - Parsed all `.github/workflows/*.yml` files as YAML.
  - Scanned Cargo-bearing workflows to confirm they configure
  `CARGO_NET_GIT_FETCH_WITH_CLI`.

  Adam Perry @ OpenAI · 2026-06-02 07:39:41 -07:00
  c097ad3e9e
• Uprev Rust toolchain pins to 1.95.0 (#24684)

  ## Summary
  - Bump the workspace Rust toolchain from `1.93.0` to `1.95.0` across
  Cargo, Bazel, CI, release workflows, devcontainers, and the Codex
  environment config.
  - Refresh `MODULE.bazel.lock` so the Bazel Rust toolchain artifacts
  match the new version.
  - Leave purpose-specific toolchains unchanged, including the
  `argument-comment-lint` nightly and the upstream `rusty_v8` `1.91.0`
  build pin.
  - Includes fixes for new lints from `just fix` and a few codex-authored
  fixes for lints without a suggestion.

  Adam Perry @ OpenAI · 2026-05-26 20:59:47 -07:00
  cca1e0ba1d
• ci: check out PR head commits in workflows (#21835)

  ## Why
  
  PR CI should test the exact commit that was pushed to the PR branch. By
  default, GitHub's `pull_request` event checks out a synthetic merge
  commit from `refs/pull/<number>/merge`, so the tested tree can include
  an implicit merge with the current base branch instead of matching the
  pushed head SHA.
  
  Using the PR head SHA makes each check result correspond to a concrete
  commit the author submitted. This also behaves better for stacked PR
  workflows, including Sapling stacks and other Git stack tooling: a
  middle PR's head commit already contains the lower stack changes in its
  tree, without pulling in commits above it or GitHub's temporary merge
  ref.
  
  ## What Changed
  
  - Set every `actions/checkout` in `pull_request` workflows under
  `.github/workflows` to use `github.event.pull_request.head.sha` on PR
  events and `github.sha` otherwise.
  - Updated `blob-size-policy` to compare
  `github.event.pull_request.base.sha` and
  `github.event.pull_request.head.sha`, since it no longer checks out
  GitHub's merge commit where `HEAD^1`/`HEAD^2` represented the PR range.
  
  ## Verification
  
  - Parsed the edited workflow YAML files with Ruby.
  - Checked that every checkout block in the `pull_request` workflows has
  the PR-head `ref`.

  Michael Bolin · 2026-05-08 15:14:33 -07:00
  24111790f0
• [codex] Address some more GHA hygiene issues (#21622)

  This does two things:
  
  - We use `persist-credentials: false` everywhere now. This is
  unfortunately not the default in GitHub Actions, but it prevents
  `actions/checkout` from dropping `secrets.GITHUB_TOKEN` onto disk.
  - We interpose (some) template expansions through environment variables.
  I've limited this to contexts that have non-fixed values; contexts that
  are fixed (like `*.result`) are not dangerous to expand directly inline
  (but maybe we should clean those up in the future for consistency
  anyways).
  
  This is a medium-risk change in terms of CI breakage: I did a scan for
  usage of `git push` and other commands that implicitly use the persisted
  credential, but couldn't find any. Even still, some implicit usages of
  the persisted credentials may be lurking. Please ping ww@ if any issues
  arise.

  William Woodruff · 2026-05-08 10:19:27 -07:00
  8bea5d231a
• [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@ 🙂

  William Woodruff · 2026-05-07 14:31:20 -07:00
  8abcc5357d
• fix: cargo deny (#20627)

  Fix cargo deny by ack the `RUSTSEC` while a fix land
  ```
    RUSTSEC-2026-0118
    NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
  
    RUSTSEC-2026-0119
    CPU exhaustion during message encoding due to O(n²) name compression
  
    Dependency path:
  
    hickory-proto 0.25.2
    └── hickory-resolver 0.25.2
        └── rama-dns 0.3.0-alpha.4
            └── rama-tcp 0.3.0-alpha.4
                └── codex-network-proxy
  ```
  
  Also upgrade some workers version to prevent this:
  ```
  warning[license-not-encountered]: license was not encountered
      ┌─ ./codex-rs/deny.toml:131:6
      │
  131 │     "OpenSSL",
      │      ━━━━━━━ unmatched license allowance
  
  warning[duplicate]: found 2 duplicate entries for crate 'base64'
     ┌─ /github/workspace/codex-rs/Cargo.lock:79:1
     │
  79 │ ╭ base64 0.21.7 registry+https://github.com/rust-lang/crates.io-index
  80 │ │ base64 0.22.1 registry+https://github.com/rust-lang/crates.io-index
     │ ╰───────────────────────────────────────────────────────────────────┘ lock entries
  ```

  jif-oai · 2026-05-01 18:15:38 +02:00
  5744b85b9a
• [codex] Pin GitHub Actions workflow references (#15828)

  Pin floating external GitHub Actions workflow refs to immutable SHAs.
  
  Why are we doing this? Please see the rationale doc:
  https://docs.google.com/document/d/1qOURCNx2zszQ0uWx7Fj5ERu4jpiYjxLVWBWgKa2wTsA/edit?tab=t.0
  
  Did this break you? Please roll back and let hintz@ know

  Drew Hintz · 2026-03-27 23:00:05 +00:00
  f4f6eca871
• bump cargo-deny-action ver (#8345)
  sayan-oai · 2025-12-19 15:23:02 -08:00
  797a68b9f2
• chore: add cargo-deny configuration (#7119)

  - add GitHub workflow running cargo-deny on push/PR
  - document cargo-deny allowlist with workspace-dep notes and advisory
  ignores
  - align workspace crates to inherit version/edition/license for
  consistent checks

  Josh McKinney · 2025-11-24 12:22:18 -08:00
  ec49b56874