CI: Customize v8 building by cconger · Pull Request #22086 · openai/codex

cconger · 2026-05-11T03:00:41Z

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.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1cf09e4acf

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

cconger · 2026-05-11T19:41:53Z

+          # Keep V8 artifact releases out of Codex's normal "latest release" channel.
+          prerelease: true
+
+      - name: Amend existing GitHub Release


This was helpful for the iteration cycle. Its feels like a hack that we maybe shouldn't support long term.

cconger · 2026-05-11T19:42:34Z

    }
+
+    #[test]
+    fn parses_crdtp_dispatchable_messages() {


This is a new test just to flex the linked crdtp libraries.

bolinfest

Off the top of my head:

I feel like there should be a Python script or something that someone should expect to be able to run to update to a new version of v8 and that this should be called out in third_party/v8/README.md.
The PR body says that we build the v8 part of the x86_64-w64-windows-gnu build from source now, with a compatible ABI. Previously, that part was not runnable, which led to carve-outs in CI like this:

codex/.github/workflows/bazel.yml

Lines 88 to 99 in e3f481d

    
                     bazel_targets=( 
        
                       //... 
        
                       # Keep standalone V8 library targets out of the ordinary Bazel CI 
        
                       # path. V8 consumers under `//codex-rs/...` still participate 
        
                       # transitively through `//...`. 
        
                       -//third_party/v8:all 
        
                       # V8-backed code-mode tests are covered by Cargo CI. Bazel CI 
        
                       # cross-compiles in several legs, and those tests are not stable in 
        
                       # that setup yet. 
        
                       -//codex-rs/code-mode:code-mode-unit-tests 
        
                       -//codex-rs/v8-poc:v8-poc-unit-tests 
        
                     )

Can those go away after this PR? (If so, I'm fine seeing that done in a separate PR since this one is already a lot to reason about.)

cconger · 2026-05-12T04:09:31Z

I updated the documentation and added a codex skill for updating the version. I'm going to try running the skill with the un-released version 14.9.207.2 as a shake down run. I imagine that we can also do a lot to try to shave off the pain of maintaining this moving forward.

Co-authored-by: Codex <noreply@openai.com>

Produce explicitly named sandbox release pairs alongside the current compatibility artifacts, and validate staged sandbox outputs before publication across the supported artifact targets. Co-authored-by: Codex <noreply@openai.com>

Co-authored-by: Codex <noreply@openai.com>

Keep non-Windows rusty-v8 consumers on the resolved 147.4.0 source-built graph. Avoid mixing LLVM's default libc++ headers into rusty-v8's custom libc++ build, propagate that configuration to external C++ deps, and export the musl-specific libc++ define through the shared header target. Also make checksum validation follow the remaining prebuilt asset version while the source-build migration is in progress. Co-authored-by: Codex <noreply@openai.com>

Add the `crdtp_binding.cc` source and CRDTP headers to the 147 Bazel V8 binding target so Windows GNU builds provide the symbols required by the `v8::crdtp` Rust APIs. Add a regression test that exercises CRDTP JSON conversion and dispatchable message parsing.

Fetch the published per-target checksum asset alongside the musl archive and binding so Cargo musl jobs keep working without re-expanding the MODULE.bazel checksum manifest contract.

cconger requested a review from bolinfest May 11, 2026 03:00

chatgpt-codex-connector Bot reviewed May 11, 2026

View reviewed changes

Comment thread third_party/v8/rusty_v8_147_4_0.sha256

Comment thread .bazelrc

cconger commented May 11, 2026

View reviewed changes

bolinfest reviewed May 11, 2026

View reviewed changes

cconger and others added 19 commits May 12, 2026 04:12

build: prepare rusty_v8 147.4.0 artifacts

54b2925

Co-authored-by: Codex <noreply@openai.com>

ci: make rusty_v8 staging select host llvm tools

15356f9

Co-authored-by: Codex <noreply@openai.com>

build: add sandbox rusty_v8 artifact lane

d3dd2d9

Produce explicitly named sandbox release pairs alongside the current compatibility artifacts, and validate staged sandbox outputs before publication across the supported artifact targets. Co-authored-by: Codex <noreply@openai.com>

ci: allow rusty_v8 release amendments

b156d79

ci: add builds for all targets

d36015e

ci: merge Unix runtime libs into rusty_v8 sandbox artifacts

2c05f33

Co-authored-by: Codex <noreply@openai.com>

Fix Darwin rusty-v8 runtime staging

4ad4a6c

ci: mirror upstream rusty_v8 artifact production

7b5a9e8

bazel: build rusty_v8 release artifacts hermetically

0cbb0b2

ci(v8): add Windows source-build canary

7369abc

ci(v8): install upstream Rust target explicitly

70be873

fix(v8): address review feedback

109b471

fix(v8): materialize staged Bazel outputs

0d1b1db

fix(v8): align windows gnullvm with 147

2f79c7a

fix(v8): verify musl artifacts with release checksums

f0da0c6

Fetch the published per-target checksum asset alongside the musl archive and binding so Cargo musl jobs keep working without re-expanding the MODULE.bazel checksum manifest contract.

docs(v8): document release update workflow

41daf10

docs(skill): add v8 update workflow

b489b06

cconger force-pushed the release/rusty-v8-147-artifacts branch from b0f35b1 to b489b06 Compare May 12, 2026 04:12

cconger mentioned this pull request May 13, 2026

ci: build v8 from base for all targets we need #21888

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CI: Customize v8 building#22086

CI: Customize v8 building#22086
cconger wants to merge 19 commits into
mainfrom
release/rusty-v8-147-artifacts

cconger commented May 11, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

Uh oh!

cconger May 11, 2026

Uh oh!

cconger May 11, 2026

Uh oh!

bolinfest left a comment

Uh oh!

cconger commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	bazel_targets=(
	//...
	# Keep standalone V8 library targets out of the ordinary Bazel CI
	# path. V8 consumers under `//codex-rs/...` still participate
	# transitively through `//...`.
	-//third_party/v8:all
	# V8-backed code-mode tests are covered by Cargo CI. Bazel CI
	# cross-compiles in several legs, and those tests are not stable in
	# that setup yet.
	-//codex-rs/code-mode:code-mode-unit-tests
	-//codex-rs/v8-poc:v8-poc-unit-tests
	)

Conversation

cconger commented May 11, 2026

Summary

Why

Implementation Notes

Windows

Validation

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

cconger May 11, 2026

Choose a reason for hiding this comment

Uh oh!

cconger May 11, 2026

Choose a reason for hiding this comment

Uh oh!

bolinfest left a comment

Choose a reason for hiding this comment

Uh oh!

cconger commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants