update-v8-version

Atualizar Versão do V8

Fluxo de Trabalho Principal

1. Leia third_party/v8/README.md e siga sua sequência de bump de versão. Trate esse documento como a fonte da verdade para o processo de release.

2. Inspecione e atualize as superfícies concretas do repositório que carregam a versão fixada:

   • codex-rs/Cargo.toml
   • codex-rs/Cargo.lock
   • MODULE.bazel
   • third_party/v8/BUILD.bazel
   • third_party/v8/README.md
   • o manifesto correspondente third_party/v8/rusty_v8_<version>.sha256 quando os demais artefatos pré-construídos mudarem

3. Mantenha os helpers de checksum existentes no loop:

   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. Valide o caminho do release candidate antes de ampliar o trabalho:

   • Prefira verificar o resultado da CI v8-canary para o branch ou PR candidato, quando existir, usando ferramentas de verificação do GitHub ou gh conforme apropriado.
   • Se a CI não estiver disponível ou o usuário solicitou uma verificação apenas local, execute a validação local mais próxima do possível para a superfície alterada e diga explicitamente que é um substituto local, não o canary completo hospedado.

5. Se o caminho do canary passar, pare aí. Resuma o resultado e incentive o usuário a fazer commit das alterações candidatas ou prosseguir com o fluxo de release solicitado. Não publique tags, releases ou pushes a menos que o usuário tenha solicitado.

Caminho de Falha

Entre neste caminho apenas quando o canary ou o caminho de build local falhar.

1. Capture o alvo da falha, o job do workflow e o primeiro erro acionável.
2. Compare a versão atualmente fixada com a versão alvo no respectivo tag ou SHA upstream. Inspecione ambos:
   • denoland/rusty_v8
   • código-fonte upstream do V8 na versão alvo fixada pelo Bazel
3. Acompanhe deltas relevantes para o build, não a rotatividade ampla de código:
   • mudanças no layout de bindings gerados
   • mudanças na nomenclatura de arquivos ou assets
   • mudanças nos alvos GN/Bazel
   • entradas personalizadas de libc++ / libc++abi / llvm-libc
   • relações de funcionalidades de sandbox ou compressão de ponteiros
   • trechos de patch em patches/ que não se aplicam mais ou não correspondem mais ao upstream
4. Rastreie cada delta com falha de volta ao grafo de build do 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. Atualize apenas as peças necessárias para restaurar o build da versão alvo e o contrato de artefatos. Mantenha explicações de patch e alterações de documentação próximas aos arquivos afetados.
6. Reexecute a validação focada. Se ficar verde, retorne ao fluxo normal e pare com um resumo conciso mais o passo de release restante.

Relatório

• Diga se a validação veio do v8-canary hospedado ou de um substituto local.
• Diferencie "bump de versão concluído" de "release publicado".
• Quando bloqueado, relate o delta upstream relevante, o arquivo do Codex que ele atinge e a próxima correção concreta a tentar.