Adam Perry @ OpenAI
740c4f269d
## Intent Keep Bazel and Starlark files consistently formatted without requiring contributors to install or version buildifier themselves. ## Implementation - Add a SHA-256-pinned, cross-platform DotSlash manifest for buildifier v8.5.1. - Run buildifier from the shared `just fmt` and `just fmt-check` driver, with Windows-safe explicit DotSlash invocation. - Provision DotSlash in formatting CI and contributor devcontainers, and document the source-build prerequisite. - Apply the initial mechanical buildifier formatting baseline.
rusty_v8 Consumer Artifacts
This directory wires the v8 crate to exact-version Bazel inputs.
Bazel consumer builds use:
- upstream
denoland/rusty_v8release archives on Windows MSVC - source-built V8 archives on Darwin, GNU Linux, musl Linux, and 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 those variables independently in MODULE.bazel to select source-built
local archives and bindings for its consumer builds.
The Bazel v8 crate feature selection enables V8's in-process sandbox for
Darwin, Linux, and Windows GNU. 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:
- Bump the
v8crate version and refreshcodex-rs/Cargo.lock. - Update the Bazel versioned inputs in
MODULE.bazel, then refresh the matching checksum manifest and generated checksums as described below. - Publish a release-candidate PR and validate that
v8-canarypasses. - If the canary is green, publish the release tag and release build.
- Once the release build completes, rerun the build on the candidate branch and verify that the final artifact builds and tests pass.
When changing the remaining prebuilt 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.gzsrc_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.gzrusty_v8_ptrcomp_sandbox_release_<target>.lib.gzon Windows MSVCsrc_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. Bazel consumers use these
source-built targets directly; Cargo release and package builds use the
published copies.
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.