Back to Details

update-v8-version

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Update V8 Version

更新V8版本

Core Workflow

核心工作流程

  1. Read 
    third_party/v8/README.md
    and follow its version-bump sequence. Treat that document as the release-process source of truth.
  2. Inspect and update the concrete repo surfaces that carry the pin:
    • codex-rs/Cargo.toml
    • codex-rs/Cargo.lock
    • MODULE.bazel
    • third_party/v8/BUILD.bazel
    • third_party/v8/README.md
    • the matching 
      third_party/v8/rusty_v8_<version>.sha256
      manifest when the remaining prebuilt inputs change
  3. Keep the existing checksum helpers in the loop:
    bash
    python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
  4. Validate the release-candidate path before broadening the work:
    • Prefer checking the 
      v8-canary
      CI result for the candidate branch or PR when one exists, using GitHub check tooling or 
      gh
      as appropriate.
    • If CI is unavailable or the user asked for a local-only check, run the closest local validation that is practical for the changed surface and say explicitly that it is a local substitute, not the full hosted canary.
  5. If the canary path passes, stop there. Summarize the result and encourage the user to commit the candidate changes or proceed with the release flow they requested. Do not publish tags, releases, or pushes unless the user asked.
  1. 阅读
    third_party/v8/README.md
    并遵循其中的版本升级步骤。将该文档视为发布流程的权威依据。
  2. 检查并更新所有包含版本固定信息的仓库文件：
    • codex-rs/Cargo.toml
    • codex-rs/Cargo.lock
    • MODULE.bazel
    • third_party/v8/BUILD.bazel
    • third_party/v8/README.md
    • 当其余预构建输入发生变化时，同步更新对应的
      third_party/v8/rusty_v8_<version>.sha256
      清单文件
  3. 保留现有校验和辅助工具的使用流程：
    bash
    python3 .github/scripts/rusty_v8_bazel.py update-module-bazel
python3 .github/scripts/rusty_v8_bazel.py check-module-bazel
python3 -m unittest discover -s .github/scripts -p test_rusty_v8_bazel.py
  4. 在扩大工作范围前，先验证候选版本发布流程：
    • 若候选分支或PR对应的
      v8-canary
      CI结果存在，优先使用GitHub检查工具或
      gh
      命令查看该结果。
    • 若CI不可用，或用户要求仅进行本地检查，则针对变更内容运行最贴近实际的本地验证，并明确说明这是本地替代方案，而非完整的托管金丝雀验证。
  5. 若金丝雀流程验证通过，则停止操作。总结验证结果，并鼓励用户提交候选变更或继续执行他们要求的发布流程。除非用户明确要求，否则不要发布标签、版本或推送代码。

Failure Path

故障处理流程

Enter this path only when the canary or local build path fails.
  1. Capture the failing target, workflow job, and first actionable error.
  2. Compare the currently pinned version with the target version at the relevant upstream tag or SHA. Inspect both: 
    • denoland/rusty_v8
    • upstream V8 source at the target Bazel-pinned version
  3. Track build-relevant deltas rather than broad source churn:
    • generated binding layout changes
    • archive or asset naming changes
    • GN/Bazel target changes
    • custom libc++ / libc++abi / llvm-libc inputs
    • sandbox or pointer-compression feature relationships
    • patch hunks in 
      patches/
      that no longer apply or no longer match upstream
  4. Trace each failing delta back into Codex's build graph: 
    • MODULE.bazel
    • third_party/v8/BUILD.bazel
    • .github/scripts/rusty_v8_bazel.py
    • .github/workflows/v8-canary.yml
    • .github/workflows/rusty-v8-release.yml
  5. Update only the pieces required to restore the target version's build and artifact contract. Keep patch explanations and doc changes close to the affected files.
  6. Re-run the focused validation. If it becomes green, return to the normal workflow and stop with a concise summary plus the remaining release step.
仅当金丝雀构建或本地构建失败时，进入此流程。
  1. 记录失败的目标任务、工作流作业以及第一个可定位的错误信息。
  2. 对比当前固定版本与目标版本在相关上游标签或SHA处的差异。检查以下两个仓库： 
    • denoland/rusty_v8
    • 目标Bazel固定版本对应的上游V8源码
  3. 重点跟踪与构建相关的差异，而非宽泛的源码变更：
    • 生成的绑定布局变化
    • 归档文件或资产命名变化
    • GN/Bazel目标配置变化
    • 自定义libc++/libc++abi/llvm-libc输入变化
    • 沙箱或指针压缩特性的关联变化
    • patches/
      目录中不再适用或与上游不匹配的补丁片段
  4. 追踪每个导致失败的差异在Codex构建图中的影响路径： 
    • MODULE.bazel
    • third_party/v8/BUILD.bazel
    • .github/scripts/rusty_v8_bazel.py
    • .github/workflows/v8-canary.yml
    • .github/workflows/rusty-v8-release.yml
  5. 仅更新恢复目标版本构建和制品契约所需的部分。将补丁说明和文档变更放在受影响文件附近。
  6. 重新运行针对性验证。若验证通过，则回到正常工作流程，并以简洁的总结加上剩余发布步骤结束操作。

Reporting

报告要求

  • Say whether validation came from hosted 
    v8-canary
    or from a local substitute.
  • Distinguish "version bump complete" from "release published".
  • When blocked, report the upstream delta that matters, the Codex file it hits, and the next concrete fix to try.
  • 明确说明验证结果来自托管的
    v8-canary
    还是本地替代方案。
  • 区分“版本升级完成”与“版本已发布”两种状态。
  • 当遇到阻塞时，报告关键的上游差异、受影响的Codex文件以及下一步可尝试的具体修复方案。