Validação completa da versão

Full Release Validation é o processo abrangente de lançamento: o ponto de entrada manual único para comprovação de pré-lançamento. A maior parte do trabalho ocorre em fluxos de trabalho filhos, para que uma máquina com falha possa ser executada novamente sem reiniciar todo o lançamento.

Execute-o a partir de uma referência confiável do fluxo de trabalho, normalmente main, e informe o branch de lançamento, a tag ou o SHA completo do commit como ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable

provider também aceita anthropic ou minimax para a integração inicial entre sistemas operacionais e o turno de ponta a ponta do agente. Os jobs filhos reutilizáveis resolvem o mecanismo do fluxo de trabalho chamado a partir de job.workflow_repository e job.workflow_sha, enquanto a entrada ref seleciona o candidato em teste. Isso mantém a lógica de validação confiável atual disponível ao validar um branch ou uma tag de lançamento mais antigos.

Cada filho disparado deve informar o mesmo SHA do fluxo de trabalho que a execução pai de Full Release Validation. Se main avançar entre os disparos do pai e dos filhos, o processo abrangente falhará de forma segura mesmo que o próprio filho seja bem-sucedido. Para uma comprovação imutável de um commit exato, use pnpm ci:full-release --sha <target-sha>. O auxiliar cria uma referência temporária release-ci/* fixada no origin/main confiável atual, transmite o SHA de destino somente como a ref candidata, reutiliza evidências estritas do destino exato quando disponíveis e exclui a referência após a validação. Informe -f reuse_evidence=false para forçar uma nova execução ou --workflow-sha <trusted-main-sha> para selecionar um commit mais antigo do fluxo de trabalho que ainda seja alcançável a partir do origin/main atual. O fluxo de trabalho nunca cria nem atualiza referências do repositório por conta própria.

release_profile=stable e release_profile=full sempre executam o teste prolongado exaustivo ao vivo/no Docker. Informe run_release_soak=true para incluir as mesmas faixas de teste prolongado com o perfil beta. A publicação estável rejeita um manifesto de validação sem esse teste prolongado e sem evidências bloqueantes de desempenho do produto.

O Package Acceptance normalmente compila o tarball candidato a partir da ref resolvida, incluindo execuções com SHA completo disparadas por pnpm ci:full-release. Após uma publicação beta, informe release_package_spec=openclaw@YYYY.M.PATCH-beta.N para reutilizar o pacote npm publicado nas verificações de lançamento, no Package Acceptance, entre sistemas operacionais, no caminho de lançamento do Docker e no Telegram com pacote. Use package_acceptance_package_spec somente quando o Package Acceptance precisar comprovar intencionalmente um pacote diferente. A faixa de pacote ao vivo do Plugin Codex segue o mesmo estado: valores publicados de release_package_spec derivam codex_plugin_spec=npm:@openclaw/codex@<version>; execuções por SHA/artefato empacotam extensions/codex a partir da referência selecionada; e os operadores podem definir codex_plugin_spec diretamente para fontes de Plugin npm:, npm-pack: ou git:. A faixa concede a aprovação explícita de instalação da CLI do Codex exigida por esse Plugin e, em seguida, executa a pré-verificação da CLI do Codex e turnos do agente OpenAI na mesma sessão.

Etapas de nível superior

Para rerun_group=all, um job Check for reusable validation evidence é executado primeiro: ele procura a validação completa anterior bem-sucedida mais recente para exatamente o mesmo SHA de destino, perfil de lançamento, configuração efetiva de teste prolongado e entradas de validação. Quando essa evidência existe, todas as faixas são ignoradas, e o verificador abrangente verifica novamente o artefato imutável do pai, as execuções filhas e os logs de disparo. Isso serve somente para recuperação de reexecução do mesmo candidato; não autoriza reutilização entre SHAs. Para um candidato alterado, execute novamente cada verificação de pacote, artefato, instalação, Docker ou provedor afetada por essa diferença. Informe reuse_evidence=false para forçar uma nova execução completa. A reutilização de evidências é executada somente a partir de main ou de uma referência canônica release-ci/* fixada por SHA, cujo commit do fluxo de trabalho permaneça na linhagem confiável de main; outras referências do fluxo de trabalho executam novamente as faixas selecionadas.

Também para rerun_group=all, um job Verify Docker runtime image assets compila o destino Docker runtime-assets com OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Ele é executado em paralelo com as outras etapas e é imposto pelo verificador abrangente; as faixas não aguardam mais por ele antes do disparo. Um rerun_group mais restrito ignora essa pré-verificação.

O processo abrangente sempre dispara o desempenho do produto no modo somente artefato. OpenClaw Performance permite a publicação de relatórios somente para execuções agendadas ou para um disparo manual que defina explicitamente publish_reports=true. A proteção do modo somente artefato deve ser concluída com êxito, comprovando que o job de publicação permaneceu ignorado. Evidências novas e reutilizadas registram controls.performanceReportPublication=artifact-only; o verificador e o seletor de reutilização rejeitam evidências sem a comprovação normalizada correspondente do filho de desempenho.

O verificador envia o manifesto canônico como full-release-validation-<run-id>-<run-attempt>. As ferramentas de evidência validam o ID do artefato, o resumo criptográfico, a execução produtora e a tentativa antes de baixar exatamente esse ID de artefato. Elas limitam o tamanho do ZIP baixado, verificam seus bytes em relação ao resumo sha256: da API REST e transmitem a única entrada delimitada permitida do manifesto sem extrair o arquivo. Um alias com nome estável permanece temporariamente para consumidores de publicação mais antigos. O verificador sempre prefere o artefato qualificado pela tentativa; como transição, ele aceita o nome estável somente para um produtor de manifesto v2 na tentativa 1. Ele rejeita esse nome legado para tentativas posteriores e para o manifesto v3.

Para ref=main com rerun_group=all, para referências release/* e para referências alfa do Tideclaw, uma execução abrangente mais recente substitui uma anterior com a mesma referência e o mesmo grupo de reexecução. Quando o pai é cancelado, seu monitor cancela todos os fluxos de trabalho filhos que ele já tenha disparado. Execuções de validação por tag e por SHA fixado não cancelam umas às outras.

Etapas das verificações de lançamento

OpenClaw Release Checks é o maior fluxo de trabalho filho. Ele resolve o destino uma vez e prepara um artefato compartilhado release-package-under-test quando etapas voltadas a pacotes ou ao Docker precisam dele.

Blocos do caminho de versão do Docker

A etapa do caminho de versão do Docker executa estes blocos quando live_suite_filter está vazio:

Use docker_lanes=<lane[,lane]> direcionado no workflow live/E2E reutilizável quando apenas um fluxo do Docker tiver falhado. Os artefatos da versão incluem comandos de nova execução por fluxo, com entradas de reutilização do artefato do pacote e da imagem quando disponíveis.

Perfis de versão

release_profile controla principalmente a abrangência de execução ao vivo/provedores nas verificações de lançamento. Ele não remove a CI completa normal, o pré-lançamento de Plugins, o teste rápido de instalação, a aceitação de pacotes nem o QA Lab. Os perfis estável e completo sempre executam uma cobertura exaustiva de E2E do repositório/ao vivo e de testes prolongados do caminho de lançamento no Docker. O perfil beta pode optar por essa cobertura com run_release_soak=true. A Aceitação de Pacotes fornece o E2E canônico do Telegram para o pacote de cada candidato completo, portanto o fluxo abrangente não duplica esse verificador ao vivo.

Adições exclusivas do perfil completo

Estas suítes são ignoradas por stable e incluídas por full:

stable inclui native-live-src-gateway-profiles-anthropic-smoke e native-live-src-gateway-profiles-opencode-go-smoke; full usa, em vez disso, os fragmentos mais abrangentes de modelos da Anthropic e do OpenCode Go. Reexecuções específicas ainda podem usar os identificadores agregados native-live-src-gateway-profiles-anthropic ou native-live-src-gateway-profiles-opencode-go.

Reexecuções específicas

Use rerun_group para evitar repetir ambientes de lançamento não relacionados:

Use live_suite_filter com rerun_group=live-e2e quando uma suíte ao vivo falhar. Os IDs de filtro válidos são definidos no fluxo reutilizável de execução ao vivo/E2E, incluindo docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker e live-codex-harness-docker.

O identificador live-gateway-advisory-docker é um identificador agregado de reexecução para seus três fragmentos de provedores, portanto ele ainda distribui a execução para todos os trabalhos consultivos do Gateway no Docker.

Use cross_os_suite_filter com rerun_group=cross-os quando uma faixa entre sistemas operacionais falhar. O filtro aceita um ID de sistema operacional, um ID de suíte ou um par sistema operacional/suíte, por exemplo, windows/packaged-upgrade, windows ou packaged-fresh. Os resumos entre sistemas operacionais incluem tempos por fase para as faixas de atualização com pacote, e comandos de longa duração imprimem linhas de Heartbeat para que uma atualização travada fique visível antes do tempo limite do trabalho.

Falhas nas verificações de lançamento de QA bloqueiam a validação normal de lançamento. A verificação de cobertura das ferramentas de execução de QA (divergência dinâmica de ferramentas entre openclaw e codex na camada padrão) também bloqueia o verificador das verificações de lançamento, embora a faixa subjacente de paridade de execução de QA seja consultiva. As execuções alfa do Tideclaw ainda podem tratar como consultivas as faixas de verificação de lançamento não relacionadas à segurança de pacotes. Com release_profile=beta, as suítes de provedores ao vivo de Run repo/live E2E validation são consultivas: as implantações de modelos de terceiros mudam independentemente de um lançamento, portanto o beta apresenta suas falhas como avisos, enquanto os perfis estável e completo as mantêm como bloqueantes. Quando live_suite_filter solicita explicitamente uma faixa condicionada de QA ao vivo, como Discord, WhatsApp ou Slack, a variável correspondente do repositório OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED deve estar habilitada; caso contrário, a captura da entrada falha em vez de ignorar silenciosamente a faixa. Execute novamente com rerun_group=qa, qa-parity ou qa-live quando precisar de evidências atualizadas de QA.

Evidências a manter

Mantenha o resumo de Full Release Validation como índice no nível do lançamento. Ele contém links para os IDs das execuções filhas e inclui tabelas dos trabalhos mais lentos. Em caso de falhas, inspecione primeiro o fluxo filho e depois execute novamente o menor identificador correspondente acima.

Artefatos úteis:

• release-package-under-test de OpenClaw Release Checks
• Artefatos do caminho de lançamento no Docker em .artifacts/docker-tests/
• package-under-test da Aceitação de Pacotes e artefatos de aceitação no Docker
• Artefatos de verificação de lançamento entre sistemas operacionais para cada sistema operacional e suíte
• Artefatos de paridade de QA, paridade de execução, Matrix e Telegram

Arquivos de fluxo de trabalho

• .github/workflows/full-release-validation.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-live-and-e2e-checks-reusable.yml
• .github/workflows/plugin-prerelease.yml
• .github/workflows/install-smoke.yml
• .github/workflows/install-smoke-reusable.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-performance.yml
• .github/workflows/npm-telegram-beta-e2e.yml