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:
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
Pararerun_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 quandolive_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 porstable 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
Usererun_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 deFull 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-testdeOpenClaw Release Checks- Artefatos do caminho de lançamento no Docker em
.artifacts/docker-tests/ package-under-testda 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