# `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
- source-built V8 archives on Darwin, GNU Linux, musl Linux, and Windows GNU
- `openai/codex` release assets for published musl release pairs

Cargo builds still use prebuilt `rusty_v8` archives by default. Only Bazel
overrides `RUSTY_V8_ARCHIVE`/`RUSTY_V8_SRC_BINDING_PATH` in `MODULE.bazel` to
select source-built local archives for its consumer builds.

Source-built Bazel V8 artifacts enable V8's in-process sandbox by default, and
the Bazel `v8` crate feature selection tracks those targets. A full consumer
rollout still needs matching sandbox-enabled archives for every non-source-built
target. Until that artifact migration lands, the rusty_v8 publishing workflows
use `--config=v8-release-compat` to preserve the current non-sandboxed release
artifact contract.

Current pinned versions:

- Rust crate: `v8 = =146.4.0`
- Embedded upstream V8 source for musl release builds: `14.6.202.9`

When bumping the Rust crate version, keep the checked-in checksum manifest and
`MODULE.bazel` in sync:

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

The commands read `third_party/v8/rusty_v8_<crate_version>.sha256` by default
and validate every matching `rusty_v8_<crate_version>` `http_file` 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`

Musl 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`

The dedicated publishing workflow is `.github/workflows/rusty-v8-release.yml`.
It builds musl release pairs from source and keeps the release artifacts as the
statically linked form:

- `//third_party/v8:rusty_v8_release_pair_x86_64_unknown_linux_musl`
- `//third_party/v8:rusty_v8_release_pair_aarch64_unknown_linux_musl`

Cargo musl builds 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` for musl because the upstream `v8`
crate hardcodes a `v<crate_version>` tag layout, while our musl 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`.
