ci: build v8 from base for all targets we need#21888
Conversation
Co-authored-by: Codex <noreply@openai.com>
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>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 11090c7526
ℹ️ 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".
| "@rules_rs//rs/experimental/platforms/config:aarch64-pc-windows-gnullvm": ":v8_146_4_0_aarch64_pc_windows_gnullvm", | ||
| "@rules_rs//rs/experimental/platforms/config:aarch64-pc-windows-msvc": ":v8_146_4_0_aarch64_pc_windows_msvc", | ||
| "@rules_rs//rs/experimental/platforms/config:aarch64-unknown-linux-gnu": ":v8_146_4_0_aarch64_unknown_linux_gnu_bazel", | ||
| ":platform_aarch64_unknown_linux_musl": ":v8_146_4_0_aarch64_unknown_linux_musl_release_base", | ||
| "@rules_rs//rs/experimental/platforms/config:x86_64-apple-darwin": ":v8_146_4_0_x86_64_apple_darwin_bazel", | ||
| "@rules_rs//rs/experimental/platforms/config:aarch64-unknown-linux-gnu": ":v8_147_4_0_aarch64_unknown_linux_gnu_bazel", | ||
| ":platform_aarch64_unknown_linux_musl": ":v8_147_4_0_aarch64_unknown_linux_musl_release_base", | ||
| "@rules_rs//rs/experimental/platforms/config:x86_64-apple-darwin": ":v8_147_4_0_x86_64_apple_darwin_bazel", | ||
| "@rules_rs//rs/experimental/platforms/config:x86_64-pc-windows-gnullvm": ":v8_146_4_0_x86_64_pc_windows_gnullvm", | ||
| "@rules_rs//rs/experimental/platforms/config:x86_64-pc-windows-msvc": ":v8_146_4_0_x86_64_pc_windows_msvc", |
There was a problem hiding this comment.
Align Windows V8 artifacts with v8 147
This commit bumps the Rust v8 crate to 147.4.0, but all Windows selectors still feed the build script 146.4.0 archives (and the adjacent binding selector keeps 146 bindings). Any Bazel Windows build will compile the 147 Rust crate against stale V8 C++ artifacts, leading to link/runtime ABI mismatches instead of the pinned version.
Useful? React with 👍 / 👎.
|
|
||
| # Bazel output paths can be reused across config flips, so existence alone | ||
| # does not prove the files match the requested flags. | ||
| bazel_build(platform, labels, compilation_mode, bazel_configs) |
There was a problem hiding this comment.
Preserve CI Bazel config when staging
ensure_bazel_output_files now always runs bazel build, but the workflow stage step only passes artifact configs, not the matrix ci-v8/ci-macos config or BuildBuddy credentials used by the prior build. Staging therefore rebuilds large V8 targets locally (or with different settings) instead of reusing the CI-built outputs, making release/canary jobs likely to timeout or fail.
Useful? React with 👍 / 👎.
Testing ci builds for a few targets.