openai/codex
1
0
Fork 0
mirror of https://github.com/openai/codex.git synced 2026-10-29 19:08:43 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
1e1b8ed914d7b4aec4d987ffaf3d1c3e97f3fa4d
codex/third_party/v8
T
History

README.md

rusty_v8 Consumer Artifacts

This directory wires the v8 crate to exact-version Bazel inputs. Bazel consumer builds use:

  • upstream denoland/rusty_v8 release archives on Windows MSVC
  • sandbox-enabled openai/codex release assets on Darwin, GNU Linux, and musl Linux
  • source-built V8 archives on Windows GNU

Local Cargo builds still use upstream prebuilt rusty_v8 archives by default. Selected Cargo CI, release, and package builds override RUSTY_V8_ARCHIVE/RUSTY_V8_SRC_BINDING_PATH with Codex release assets. Bazel sets the same overrides in MODULE.bazel to select the matching release archive and binding for its consumer builds.

The Bazel v8 crate feature selection enables V8's in-process sandbox for Darwin, Linux, and Windows GNU. Darwin and Linux consume the matching published sandbox artifacts. Windows GNU continues to build from source because the release workflow does not publish Windows GNU artifacts. Windows MSVC remains on upstream non-sandboxed prebuilts.

Current pinned versions:

  • Rust crate: v8 = =149.2.0
  • Embedded upstream V8 source for Bazel-produced release builds: 14.9.207.2

Updating to a new v8 release

Use this as the maintainer flow for a version bump:

  1. Bump the v8 crate version and refresh codex-rs/Cargo.lock.
  2. Update the Bazel versioned inputs in MODULE.bazel, then refresh the matching checksum manifest and generated checksums as described below.
  3. Publish a release-candidate PR and validate that v8-canary passes.
  4. If the canary is green, publish the release tag and release build.
  5. Once the release build completes, rerun the build on the candidate branch and verify that the final artifact builds and tests pass.

When changing rusty_v8 http_file inputs, keep the checked-in checksum manifest and MODULE.bazel in sync:

python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel

The commands default to the single rusty_v8_* http_file version still present in MODULE.bazel and validate every matching entry. CI runs the check command to block checksum drift.

The consumer-facing selectors are:

  • //third_party/v8:rusty_v8_archive_for_target
  • //third_party/v8:rusty_v8_binding_for_target

Published release assets are expected at the tag:

  • rusty-v8-v<crate_version>

with these raw asset names:

  • librusty_v8_release_<target>.a.gz
  • src_binding_release_<target>.rs

During the sandbox rollout, sandbox-enabled assets are published alongside those current assets on the same tag, with the Rust crate's sandbox feature suffix in their raw names:

  • librusty_v8_ptrcomp_sandbox_release_<target>.a.gz
  • rusty_v8_ptrcomp_sandbox_release_<target>.lib.gz on Windows MSVC
  • src_binding_ptrcomp_sandbox_release_<target>.rs

The dedicated publishing workflow is .github/workflows/rusty-v8-release.yml. Tagged runs build release artifacts from the Bazel graph itself:

  • //third_party/v8:rusty_v8_release_pair_x86_64_apple_darwin
  • //third_party/v8:rusty_v8_release_pair_aarch64_apple_darwin
  • //third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_gnu
  • //third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_gnu
  • //third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl
  • //third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl

The same run also builds the matching sandbox pair targets:

  • //third_party/v8:rusty_v8_sandbox_release_pair_x86_64_apple_darwin
  • //third_party/v8:rusty_v8_sandbox_release_pair_aarch64_apple_darwin
  • //third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_gnu
  • //third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_gnu
  • //third_party/v8:rusty_v8_sandbox_release_pair_x86_64_unknown_linux_musl
  • //third_party/v8:rusty_v8_sandbox_release_pair_aarch64_unknown_linux_musl

The workflow also builds sandbox-enabled x86_64-pc-windows-msvc and aarch64-pc-windows-msvc archive/binding pairs from upstream rusty_v8 source. Those ABI-specific outputs cannot be produced by Codex's Bazel Windows GNU toolchain.

The Bazel graph pins the same libc++, libc++abi, and llvm-libc source revisions used by rusty_v8 v149.2.0, compiles published artifact targets with --config=rusty-v8-upstream-libcxx, and folds the matching runtime objects into the final static archive so consumers can link it with the v8 crate's default use_custom_libcxx feature. The config keeps the object files and the bundled runtime on Chromium's std::__Cr ABI namespace instead of mixing those objects with the toolchain libc++ default namespace. The source-built targets remain in the graph as the producers for future release tags; the consumer selectors use the immutable assets from the current tag.

MSVC is not part of the Bazel-produced matrix yet. The repository's current hermetic Windows C++ platform is windows-gnullvm/x86_64-w64-windows-gnu, so it cannot truthfully reproduce upstream's *-pc-windows-msvc archives until we add a real MSVC-targeting C++ toolchain to the Bazel graph.

Release and CI Cargo builds for Darwin and Linux use RUSTY_V8_ARCHIVE plus a downloaded RUSTY_V8_SRC_BINDING_PATH to point at those openai/codex release assets directly. We do not use RUSTY_V8_MIRROR because the upstream v8 crate hardcodes a v<crate_version> tag layout, while our artifacts are published under rusty-v8-v<crate_version>.

Do not mix artifacts across crate versions. The archive and binding must match the exact resolved v8 crate version in codex-rs/Cargo.lock.

Reference in New Issue View Git Blame Copy Permalink