update-v8-version

V8 バージョンの更新

コアワークフロー

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. 既存のチェックサムヘルパーを引き続き使用してください。

   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 を利用できない場合、またはユーザーがローカルのみの確認を求めている場合は、変更箇所に対して現実的な範囲で最も近いローカル検証を実行し、ホスト型の完全な canary ではなくローカルでの代替検証であることを明記してください。

5. canary の経路が成功したら、そこで終了してください。結果をまとめ、候補の変更をコミットするか、依頼されたリリース手順に進むようユーザーに促してください。ユーザーから依頼がない限り、タグ、リリース、プッシュを公開しないでください。

失敗時の手順

canary またはローカルビルドの経路が失敗した場合にのみ、この手順に進んでください。

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. 対象を絞った検証を再実行してください。成功したら通常のワークフローに戻り、簡潔な要約と残りのリリース手順を示して終了してください。

報告

• 検証がホスト型の v8-canary によるものか、ローカルの代替検証によるものかを明記してください。
• 「バージョン更新完了」と「リリース公開済み」を区別してください。
• 作業が阻まれた場合は、関係する上流の差分、影響を受ける Codex のファイル、次に試す具体的な修正を報告してください。