CI de Lançamento do OpenClaw
Use isso com $openclaw-release-maintainer e $openclaw-testing quando um candidato a lançamento precisar de validação completa, verificação de instalação/atualização, verificações de provedor ativo ou recuperação de CI.
Diretrizes
- Sem aumento de versão, tag, publicação npm, lançamento no GitHub ou promoção de lançamento sem aprovação explícita do operador.
- Valide segredos do provedor antes de despachar matrizes de lançamento completas e caras.
- Não defina segredos do GitHub a partir de candidatos do 1Password não validados. Se um candidato retornar 401/403, deixe o segredo existente em paz e relate o provedor ausente exato.
- Use
$one-passwordpara leituras/gravações de segredos: uma sessão tmux persistente, apenas itens direcionados, sem saída de segredo. - Acompanhe uma execução pai mais resumos compactos de filhos. Evite loops amplos de
gh run view; a cota REST é fácil de queimar. - Obtenha logs apenas para trabalhos com falha ou atualmente bloqueadores. Se a cota estiver baixa, pare de sondar e espere pela redefinição.
- Trate falhas de provedor ativo separadamente de falhas de código: prove validade da chave, status HTTP do provedor, evidência de repetição e faixa exata com falha antes de editar o código.
Pré-verificação
Antes da validação completa do lançamento:
node .agents/skills/openclaw-release-ci/scripts/verify-provider-secrets.mjs --required openai,anthropic,fireworks
gh api rate_limit --jq '.resources.core'
git status --short --branch
git rev-parse HEAD
Os valores da conta de serviço do 1Password são a primeira fonte para a pré-verificação do provedor de lançamento. Injete essas chaves direcionadas exatas primeiro, então execute o verificador; use env ambiente apenas quando ele já foi intencionalmente injetado para este lançamento. O script imprime apenas o status do provedor e a classe HTTP, nunca tokens.
Despacho
Prefira o fluxo de trabalho confiável em main, aponte para o SHA de lançamento exato:
gh workflow run full-release-validation.yml \
--repo openclaw/openclaw \
--ref main \
-f ref=<release-sha> \
-f provider=openai \
-f mode=both \
-f release_profile=full \
-f rerun_group=all
Use release_profile=stable a menos que o operador peça explicitamente pela matriz ampla de provedor/mídia consultiva. Use rerun_group estreito após correções focadas.
Acompanhamento
Use o auxiliar de resumo em vez de sondagem bruta repetida:
node .agents/skills/openclaw-release-ci/scripts/release-ci-summary.mjs <full-release-run-id>
Em seguida, acompanhe apenas quando útil:
gh run watch <full-release-run-id> --repo openclaw/openclaw --exit-status
Pare os observadores antes de encerrar a vez ou mudar de estratégia.
Triagem de Falhas
- Confirme o SHA pai e os IDs de execução dos filhos.
- Liste apenas trabalhos com falha:
gh run view <child-run-id> --repo openclaw/openclaw --json jobs \ --jq '.jobs[] | select(.conclusion=="failure" or .conclusion=="timed_out" or .conclusion=="cancelled") | [.databaseId,.name,.conclusion,.url] | @tsv' - Obtenha o log de um trabalho com falha. Se estiver com limite de taxa, observe o tempo de redefinição e evite mais chamadas REST.
- Para falhas relacionadas a segredos, valide o endpoint do provedor a partir da mesma fonte de segredo antes de editar o código.
- Para falhas de cache ativo, inspecione se é chave ausente/inválida, texto vazio, recusa do provedor, tempo limite ou falta de linha de base. Não enfraqueça as portas de lançamento sem evidência clara do provedor.
- Corrija de forma estreita, execute prova local/alterada, faça commit, push, execute novamente o menor grupo correspondente.
Evidência
Registre:
- SHA de lançamento
- URL da execução pai completa
- IDs de execução dos filhos e conclusões: CI, Verificações de Lançamento, Pré-lançamento de Plugin, NPM Telegram
- comandos de prova local direcionados
- resultado da pré-verificação de segredo do provedor
- lacunas conhecidas ou falhas não relacionadas
Para lições e padrões de recuperação, leia references/release-ci-notes.md.