2 Commits

• CI: Customize v8 building (#22086)

  ## Summary
  
  Move the rusty_v8 artifact production into hermetic Bazel path and bump
  the `v8` crate to `147.4.0`
  
  The new flow builds V8 release artifacts from source for Darwin and
  Linux targets, publishes both the current release-compatible artifacts
  and sandbox-enabled variants, and keeps Cargo consumers on prebuilt
  binaries by continuing to feed the `v8` crate the archive and generated
  binding files it already expects.
  
  ## Why
  
  We need control over V8 build-time features without giving up prebuilt
  artifacts for downstream Cargo builds.
  
  Upstream `rusty_v8` already supports source-only features such as
  `v8_enable_sandbox`, but its normal prebuilt release assets do not cover
  every feature combination we need. Building the artifacts ourselves lets
  us enable settings such as the V8 sandbox and pointer compression at
  artifact build time, then publish those outputs so ordinary Cargo builds
  can still consume prebuilts instead of compiling V8 locally.
  
  This keeps the fast consumer experience of prebuilt `rusty_v8` archives
  while giving us a reproducible path to ship featureful variants that
  upstream does not currently publish for us.
  
  ## Implementation Notes
  
  The Bazel graph in this PR is not copied wholesale from `rusty_v8`;
  `rusty_v8`'s normal source build is still GN/Ninja-based.
  
  Instead, this change starts from upstream V8's Bazel rules and adapts
  them to Codex's hermetic toolchains and dependency layout. Where we
  intentionally follow `rusty_v8`, we mirror its existing artifact
  contract:
  
  - the same `v8` crate version and generated binding expectations
  - the same sandbox feature relationship, where sandboxing requires
  pointer compression
  - the same custom libc++ model expected by Cargo's default
  `use_custom_libcxx` feature
  - the same release-style archive plus `src_binding` outputs consumed by
  the `v8` crate
  
  To preserve that contract, the Bazel release path pins the libc++,
  libc++abi, and llvm-libc revisions used by `rusty_v8 v147.4.0`, builds
  release artifacts with `--config=rusty-v8-upstream-libcxx`, and folds
  the matching runtime objects into the final static archive.
  
  ## Windows
  
  Windows is annoyingly handled differently.
  
  Codex's current hermetic Bazel Windows C++ platform is `windows-gnullvm`
  / `x86_64-w64-windows-gnu`, while upstream `rusty_v8` publishes Windows
  prebuilts for `*-pc-windows-msvc`. Those are different ABIs, so the
  Bazel graph cannot truthfully reproduce the upstream MSVC artifacts
  until we add a real MSVC-targeting C++ toolchain.
  
  For now:
  
  - Windows MSVC consumers continue to use upstream `rusty_v8` release
  archives.
  - Windows GNU targets are built in-tree so they link against a matching
  GNU ABI.
  - The canary workflow separately exercises upstream `rusty_v8` source
  builds for MSVC sandbox artifacts, but MSVC is not yet part of the
  Bazel-produced release matrix.
  
  ## Validation
  This PR is technically self validating through CI. I have already
  published it as a release tag so the artifacts from this branch are
  published to
  https://github.com/openai/codex/releases/tag/rusty-v8-v147.4.0 CI for
  this PR should therefore consume our own release targets. I have also
  locally tested for linux and darwin.
  
  ---------
  
  Co-authored-by: Codex <noreply@openai.com>

  Channing Conger · 2026-05-18 21:33:05 -07:00
  7cdeab33d1
• fix: pin inputs (#17471)

  ## Summary
  - Pin Rust git patch dependencies to immutable revisions and make
  cargo-deny reject unknown git and registry sources unless explicitly
  allowlisted.
  - Add checked-in SHA-256 coverage for the current rusty_v8 release
  assets, wire those hashes into Bazel, and verify CI override downloads
  before use.
  - Add rusty_v8 MODULE.bazel update/check tooling plus a Bazel CI guard
  so future V8 bumps cannot drift from the checked-in checksum manifest.
  - Pin release/lint cargo installs and all external GitHub Actions refs
  to immutable inputs.
  
  ## Future V8 bump flow
  Run these after updating the resolved `v8` crate version and checksum
  manifest:
  
  ```bash
  python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
  python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
  ```
  
  The update command rewrites the matching `rusty_v8_<crate_version>`
  `http_file` SHA-256 values in `MODULE.bazel` from
  `third_party/v8/rusty_v8_<crate_version>.sha256`. The check command is
  also wired into Bazel CI to block drift.
  
  ## Notes
  - This intentionally excludes RustSec dependency upgrades and
  bubblewrap-related changes per request.
  - The branch was rebased onto the latest origin/main before opening the
  PR.
  
  ## Validation
  - cargo fetch --locked
  - cargo deny check advisories
  - cargo deny check
  - cargo deny check sources
  - python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
  - python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
  - python3 -m unittest discover -s .github/scripts -p
  'test_rusty_v8_bazel.py'
  - python3 -m py_compile .github/scripts/rusty_v8_bazel.py
  .github/scripts/rusty_v8_module_bazel.py
  .github/scripts/test_rusty_v8_bazel.py
  - repo-wide GitHub Actions `uses:` audit: all external action refs are
  pinned to 40-character SHAs
  - yq eval on touched workflows and local actions
  - git diff --check
  - just bazel-lock-check
  
  ## Hash verification
  - Confirmed `MODULE.bazel` hashes match
  `third_party/v8/rusty_v8_146_4_0.sha256`.
  - Confirmed GitHub release asset digests for denoland/rusty_v8
  `v146.4.0` and openai/codex `rusty-v8-v146.4.0` match the checked-in
  hashes.
  - Streamed and SHA-256 hashed all 10 `MODULE.bazel` rusty_v8 asset URLs
  locally; every downloaded byte stream matched both `MODULE.bazel` and
  the checked-in manifest.
  
  ## Pin verification
  - Confirmed signing-action pins match the peeled commits for their tag
  comments: `sigstore/cosign-installer@v3.7.0`, `azure/login@v2`, and
  `azure/trusted-signing-action@v0`.
  - Pinned the remaining tag-based action refs in Bazel CI/setup:
  `actions/setup-node@v6`, `facebook/install-dotslash@v2`,
  `bazelbuild/setup-bazelisk@v3`, and `actions/cache/restore@v5`.
  - Normalized all `bazelbuild/setup-bazelisk@v3` refs to the peeled
  commit behind the annotated tag.
  - Audited Cargo git dependencies: every manifest git dependency uses
  `rev` only, every `Cargo.lock` git source has `?rev=<sha>#<same-sha>`,
  and `cargo deny check sources` passes with `required-git-spec = "rev"`.
  - Shallow-fetched each distinct git dependency repo at its pinned SHA
  and verified Git reports each object as a commit.

  viyatb-oai · 2026-04-14 01:45:41 +00:00
  d9a385ac8c