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ファイル、および次に試す具体的な修正を報告します。