release-openclaw-nightly

Lançamento Nightly

Use para automação de lançamento alfa/nightly do Tideclaw/OpenClaw, triggers manuais alfa, preparação beta, reparo de branches de lançamento e portabilidade pós-lançamento. Carregue $release-private se existir antes de usar caminhos de host Tideclaw, IDs de cron ou IDs de roteamento Discord.

Política

• Alfa/nightly é executado a cada 12h ou por trigger manual.
• Beta é acionado manualmente pelo Discord a partir de um branch alfa/de lançamento comprovado.
• Stable/latest sempre precisa de confirmação humana explícita.
• Nunca publique a partir de um checkout sujo ou diretamente de main.
• Main pode estar ocupado ou quebrado; o trabalho alfa deve ser isolado para que falhas transitórias no main não bloqueiem um nightly utilizável.
• Publique somente após a prova do branch de lançamento estar verde.
• Após um alfa bem-sucedido, faça forward-port dos commits do branch de lançamento de volta para main e prove que o CI do main está verde.
• PRs de forward-port contêm apenas correções reutilizáveis necessárias para fazer as verificações nightly/de lançamento passarem. Eles não devem conter bumps de versão alfa, notas de lançamento, entradas de changelog de lançamento, tags, artefatos gerados ou atualizações de arquivo de estado.
• Mantenha apenas branches alfa/nightly dos últimos 3 dias, mais qualquer branch com uma execução ativa, PR aberto ou tag de lançamento.
• Nunca execute dumps amplos de env/token. Para escritas no GitHub no host Tideclaw, use o wrapper de escrita gh do Tideclaw abaixo.

Identidade

O Tideclaw deve commitar sob sua própria identidade de máquina em branches de lançamento e branches de forward-port:

git config user.name "Tideclaw"
git config user.email "[email protected]"

Isso é bom para auditabilidade se os commits forem claramente de autoria de máquina e controlados por CI. Evite pushes diretos para main protegido; faça forward-port via PR/automerge, a menos que a política do repositório permita explicitamente que o bot faça push após verificações verdes. Inclua Co-authored-by humano apenas quando um humano fornecer o patch ou o texto explícito do commit.

Forma do Branch

• Prefixo do branch: tideclaw/alpha/
• Nome do branch: tideclaw/alpha/YYYY-MM-DD-HHMMZ
• Base: SHA atual de origin/main no momento do trigger.
• Arquivo de estado: resolva a partir de $release-private no host Tideclaw.
• Tag de lançamento: vYYYY.M.PATCH-alpha.N
• npm dist-tag: alpha

PATCH é um número sequencial mensal de train de lançamento, nunca o dia do calendário. Determine o train alfa a partir de lançamentos estáveis e beta; ignore números de patch apenas alfa ao escolher o próximo train. Use um a mais que o maior patch estável/beta do mês, depois incremente apenas alpha.N para nightlies repetidos naquele train. Se existir um beta naquele próximo patch, mova alfa para o train seguinte. Tags apenas alfa legadas com números de patch inflados não avançam a numeração beta/estável.

Não reutilize branches alfa antigos para uma nova execução. Se reexecutar o mesmo SHA base, crie um novo branch com timestamp e registre o motivo.

Início

1. Trabalhe no checkout do host Tideclaw a partir de $release-private.
2. Faça fetch primeiro:

git fetch origin main --tags --prune
git switch main
git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"

3. Leia os documentos/scripts de lançamento do repositório antes de alterar qualquer coisa:
   • AGENTS.md
   • docs de lançamento em docs/
   • scripts de lançamento em scripts/
   • .github/workflows/*release*
4. Compare $BASE_SHA com o último estado alfa bem-sucedido e as tags alfa atuais do git/npm/GitHub. Se já foi lançado, reporte o pulo e não publique.

Trigger manual:

CRON_ID="<de release-private>"
OPENCLAW_ALLOW_ROOT=1 openclaw cron run "$CRON_ID" --expect-final --timeout 21600000

Trigger Alfa pelo Discord

O Tideclaw pode executar alfa imediatamente a partir do Discord quando um mantenedor mencionar o Tideclaw em #releases ou #maintainers.

Formas aceitas:

@Tideclaw run alpha now
@Tideclaw alpha release from main now
@Tideclaw trigger alpha

Regras:

1. Trate isso como um trigger alfa manual equivalente ao job cron alfa.
2. Comece a partir do origin/main atual e crie um novo branch tideclaw/alpha/YYYY-MM-DD-HHMMZ.
3. Siga o fluxo de trabalho alfa normal: reutilize correções anteriores, execute verificações locais, corrija no branch alfa, execute o CI de lançamento, publique alfa após gates verdes, depois faça forward-port de correções reutilizáveis via PR apenas de correções.
4. Se outra execução de lançamento alfa/beta/estável já estiver ativa, reporte o branch/execução ativos e pare.
5. O trigger #maintainers requer uma menção explícita ao Tideclaw; não reaja a conversas de lançamento não mencionadas lá.
6. Resolva IDs de função/usuário do Discord e notas de hotfix do host ativo a partir de $release-private.

Trigger Beta pelo Discord

O Tideclaw pode executar lançamentos beta a partir de #releases ou comandos mencionados em #maintainers somente quando um mantenedor enviar um trigger beta explícito. Trate isso como aprovação humana para beta, não para stable/latest.

Formas aceitas:

@Tideclaw beta release from vYYYY.M.PATCH-alpha.N
@Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ
@Tideclaw beta release from latest proven alpha

Regras:

1. Exija as palavras beta release e uma tag/branch alfa de origem, ou latest proven alpha.
2. Se a origem for ambígua, faça uma pergunta esclarecedora em #releases e pare.
3. Verifique a origem alfa primeiro: lançamento do GitHub, pacote npm alpha, CI de lançamento, arquivo de estado registrado e SHA do branch/tag.
4. Crie um novo branch beta tideclaw/beta/YYYY-MM-DD-HHMMZ a partir da origem alfa comprovada, não diretamente de um main em movimento.
5. Reutilize/squash apenas correções de estabilização já comprovadas no alfa. Não importe mecânicas de lançamento alfa não relacionadas, a menos que os documentos de lançamento beta as exijam.
6. Compute beta como vYYYY.M.PATCH-beta.N, combinando com npm --tag beta. Ignore números de patch apenas alfa ao selecionar o train beta.
7. Execute validação de lançamento beta/preflight/CI de lançamento completo e corrija falhas no branch beta.
8. Publique beta somente após gates beta verdes. Use GitHub Actions/OIDC, nunca publique npm diretamente do host.
9. O resumo final no Discord deve incluir alfa de origem, tag/versão beta, branch, commits de correção, IDs de execução do workflow, prova npm/GitHub e qualquer motivo de pulo/bloqueio.
10. Após o beta ser publicado, faça forward-port de correções reutilizáveis para main usando as mesmas regras de PR apenas de correções abaixo.

Reutilizar Correções Anteriores

Antes de executar as verificações, explore branches alfa recentes do Tideclaw em busca de correções feitas durante tentativas de lançamento anteriores:

1. Leia o arquivo de estado do Tideclaw de $release-private para o último branch alfa bem-sucedido e SHAs de commits de correção.
2. Liste branches remotos recentes:

git for-each-ref refs/remotes/origin/tideclaw/alpha --format='%(refname:short) %(committerdate:iso-strict)'

3. Considere apenas branches alfa do Tideclaw dos últimos 3 dias mais o último branch alfa bem-sucedido.
4. Para cada branch candidato, inspecione commits que não estão no origin/main atual:

git log --no-merges --reverse --format='%H%x09%s' origin/main..origin/tideclaw/alpha/YYYY-MM-DD-HHMMZ

5. Cherry-pick apenas correções reais de estabilização que ainda se aplicam ao novo branch alfa. Prefira commits registrados como fixCommitShas no arquivo de estado.
6. Pule bumps de versão, entradas de changelog de lançamento, artefatos de tag, notas de lançamento geradas, commits apenas de arquivo de estado e instrumentação de depuração pontual.
7. Se um cherry-pick conflitar, verifique se o main atual já contém uma correção equivalente. Se não, resolva minimamente e mantenha a mensagem do commit clara.
8. Registre SHAs de commits reutilizados separadamente dos SHAs de correção recém-criados no estado alfa e no resumo final do Discord.

Use git cherry, git range-diff e reexecuções de teste direcionadas para evitar duplicar correções já presentes no main.

Loop de Reparo

Use o branch como uma superfície de reparo de release candidate:

1. Execute verificações locais estreitas primeiro: testes alterados, preflight de lançamento, gates de tipo/lint/build exigidos pelos documentos de lançamento.
2. Se as verificações locais falharem, corrija no branch alfa com commits mínimos.
3. Commit cada correção coerente como Tideclaw.
4. Reexecute a verificação local que falhou após cada correção.
5. Não esconda falhas editando baselines, listas de falhas esperadas, arquivos ignore ou inventário de lançamento, a menos que os documentos de lançamento exijam explicitamente e o diff seja justificado.
6. Se uma falha for flaky, reexecute uma vez; se ainda vermelha, trate como real.
7. Se a correção for claramente útil para o main, mantenha-a pequena e portável. Evite refatorações amplas durante a estabilização alfa.

Exemplos de commit:

git add <files>
git commit -m "fix: estabilizar preflight de lançamento alfa"
git push -u origin "$BRANCH"

CI de Lançamento

Após prova local:

1. Compute o próximo vYYYY.M.PATCH-alpha.N a partir de tags git existentes, versões npm e lançamentos GitHub. Selecione PATCH a partir de trains estáveis/beta, não a data ou o patch apenas alfa mais alto. Reutilize o mesmo train alfa e incremente alpha.N até que aquele patch tenha um beta; após um beta existir, use o patch seguinte para novas builds alfa.
2. Faça a versão do pacote do branch alfa e os metadados de lançamento corresponderem a essa tag, commite e faça push do branch.
3. Execute a validação de lançamento a partir do branch alfa, usando GitHub CLI, não ferramentas de browser/fetch. No host Tideclaw, gh puro é um wrapper sandbox Codex somente leitura; use /usr/local/bin/gh-tideclaw-write para comandos com capacidade de escrita, como workflow run, run cancel e dispatch de publicação:

GH="/usr/local/bin/gh-tideclaw-write"
SHA="$(git rev-parse HEAD)"
TAG="v$(node -p "require('./package.json').version")"
BRANCH="$(git branch --show-current)"

"$GH" workflow run full-release-validation.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f ref="$BRANCH" \
  -f release_profile=beta \
  -f rerun_group=all

"$GH" workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$SHA" \
  -f preflight_only=true \
  -f npm_dist_tag=alpha

4. Observe os IDs exatos de execução do workflow e o SHA head com gh run list, gh run view e gh api. gh somente leitura é suficiente para polling; use $GH apenas quando um comando mutar o GitHub. Não use Codex browser/fetch para polling da API GitHub; execuções anteriores do Tideclaw falharam lá após preflight bem-sucedido.
5. Para alfa, os gates bloqueadores são aqueles que o Tideclaw pode reparar diretamente ou que provam a segurança do pacote: CI normal, pré-lançamento de plugin, npm preflight, preparação de pacote, smoke de instalação, tag/atingibilidade e verificação de publicação. Trate falhas cross-OS, canal ao vivo, QA Lab, aceitação de pacote, Docker E2E longo e Telegram E2E como consultivas; reporte-as no Discord e continue se os gates bloqueadores estiverem verdes.
   • Se rerun_group=all estiver travado apenas em faixas consultivas após CI, pré-lançamento de plugin, npm preflight, preparação de pacote e smoke de instalação estarem verdes, dispare uma Validação Completa de Lançamento focada no mesmo head com -f rerun_group=install-smoke. Use essa execução focada bem-sucedida como prova de publicação e inclua os IDs de execução consultiva separada de CI/plugin/completo no resumo do Discord.
6. Se um gate bloqueador falhar, corrija no branch alfa, faça push e reexecute apenas o CI de lançamento que falhou ou necessário. Se o commit mudar, descarte IDs de execução de preflight/validação completa antigos e reexecute para o novo head.
7. Após a validação completa e o npm preflight estarem verdes no mesmo head do branch, crie e faça push da tag de lançamento a partir desse commit exato:

git tag -a "$TAG" "$SHA" -m "openclaw ${TAG#v}"
git push origin "$TAG"

8. Dispache o wrapper de publicação a partir do mesmo branch alfa. Use o ID de execução bem-sucedido do npm preflight e o ID de execução da validação completa de lançamento mais a tentativa exata do mesmo head SHA:

FULL_RELEASE_VALIDATION_RUN_ATTEMPT="$(gh api \
  "repos/openclaw/openclaw/actions/runs/${FULL_RELEASE_VALIDATION_RUN_ID}" \
  --jq .run_attempt)"
"$GH" workflow run openclaw-release-publish.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$TAG" \
  -f preflight_run_id="$NPM_PREFLIGHT_RUN_ID" \
  -f full_release_validation_run_id="$FULL_RELEASE_VALIDATION_RUN_ID" \
  -f full_release_validation_run_attempt="$FULL_RELEASE_VALIDATION_RUN_ATTEMPT" \
  -f npm_dist_tag=alpha \
  -f plugin_publish_scope=all-publishable \
  -f publish_openclaw_npm=true \
  -f release_profile=beta \
  -f wait_for_clawhub=false

9. Observe o wrapper de publicação mais execuções filhas. Se openclaw-npm-release.yml estiver esperando pelo ambiente npm-release e o Tideclaw não puder aprová-lo, reporte isso como o único bloqueador; não considere o lançamento concluído.
10. Não publique npm diretamente do host; use GitHub Actions/OIDC.

Importante: openclaw-npm-release.yml com preflight_only=true apenas prepara artefatos. Ele não publica. Um alfa bem-sucedido requer o wrapper openclaw-release-publish.yml posterior, uma tag git enviada, npm alpha dist-tag prova e uma prerelease do GitHub.

Verificar Alfa Publicado

O lançamento não está concluído até que todos sejam verdadeiros:

• A tag GitHub existe.
• O Release GitHub existe e está marcado como prerelease.
• O corpo do Release vincula a página de versão npm, tarball do registro, integridade e CI/prova.
• npm view openclaw@<versão> mostra a versão exata, dist-tag alpha, tarball, integridade e hora de publicação.
• Smoke de pacote instalado segue os documentos de lançamento do repositório.
• O arquivo de estado do Tideclaw de $release-private registra versão, tag, SHA base, branch, SHAs de commits de correção, IDs de execução do workflow, integridade npm e timestamp.

Resumo final no Discord em #releases:

• tag/versão
• SHA base
• branch
• commits de correção
• IDs de execução do workflow
• prova npm/GitHub
• motivo ignorado/bloqueado se não lançado

Use links Markdown seguros para Discord com alvos de colchetes angulares. Nunca imprima segredos.

Forward-Port

Após um alfa bem-sucedido, crie um PR apenas de correções de volta para main:

1. Crie/atualize um branch de forward-port a partir do origin/main atual:

git fetch origin main --prune
git switch -c "tideclaw/forward-port/$(date -u +%Y-%m-%d-%H%MZ)" origin/main

2. Cherry-pick apenas commits do branch de lançamento que são correções reais necessárias para fazer as verificações nightly/de lançamento passarem.
3. Exclua bumps de versão alfa, entradas de changelog, notas de lançamento, artefatos de tag, ativos de lançamento gerados, commits apenas de arquivo de estado e qualquer commit cujo único propósito foi publicar o alfa.
4. Se um commit misturar uma correção real com alterações de versão/lançamento, divida-o: replique apenas os hunks de correção em um novo commit e descarte o restante.
5. Se um cherry-pick conflitar, resolva minimamente, preservando a correção real. Se o main já contiver a correção equivalente, pule o commit.
6. Aplique o tipo de PR adequado baseado se as mudanças corrigem um bug (fix:) ou adicionam manutenção/teste (chore:, test:, ci:, docs:, refactor:). Use títulos de PR descritivos que descrevam o que é corrigido, não de onde veio o commit.
7. Abra o PR e marque auto-merge se a política do repositório permitir:

git push -u origin tideclaw/forward-port/YYYY-MM-DD-HHMMZ

PR_URL="$(gh pr create \
  --base main \
  --head tideclaw/forward-port/YYYY-MM-DD-HHMMZ \
  --title "fix: correções de forward-port do lançamento alfa $TAG" \
  --body "Forward-port de correções do branch de lançamento alfa \`$TAG\` (\`$BRANCH\`)." \
  --label forward-port \
  --label tideclaw)"

gh pr merge "$PR_URL" --auto --squash

Use $GH para criação de PR se o token somente leitura padrão não tiver permissão; caso contrário, gh é suficiente. 8. Anexe o URL do PR ao resumo final do Discord. 9. Monitore o PR CI do forward-port. Se falhar e a causa for uma correção ausente do forward-port, corrija atualizando o branch de forward-port com novos commits. Se a falha for pré-existente no main, não bloqueie; reporte no Discord. 10. Após o merge do PR de forward-port, verifique se o CI do main está verde. Se o PR introduzir uma regressão, corrija imediatamente com um PR de reversão ou correção.

Retenção de Branch

Após o forward-port, execute limpeza:

1. Liste branches alfa remotos:

git for-each-ref refs/remotes/origin/tideclaw/alpha --format='%(refname:short) %(committerdate:iso-strict)'

2. Considere apenas branches dos últimos 3 dias.
3. Mantenha:
   • O branch com a execução CI mais recente ainda em andamento.
   • Qualquer branch referenciado por uma issue ou PR aberto.
   • O branch que tem a tag de lançamento mais recente.
4. Exclua com segurança branches que não estão nos critérios de retenção e não têm execuções ativas, PRs abertos ou tags:

git push origin --delete tideclaw/alpha/YYYY-MM-DD-HHMMZ

5. Também exclua branches de forward-port já mesclados com mais de 7 dias.
6. Para exclusões com dependências abertas, reporte-as e não exclua.
7. Resuma exclusões e retenções no resumo final do Discord após um lançamento alfa.

Resumo do Discord

Após publicar, enviar para o canal #releases (canal de lançamentos) ou o canal de releases configurado:

**Lançamento Alfa `v...` publicado**
- Tag: <https://github.com/openclaw/openclaw/releases/tag/v...>
- npm: <https://www.npmjs.com/package/openclaw/v/v...>
- SHA base: `abc1234`
- Branch: `tideclaw/alpha/YYYY-MM-DD-HHMMZ`
- Correções: `def5678`, `ghi9012` (de `<branch-anterior>`)
- Execuções CI: `1234567890`, `9876543210`
- PR forward-port: <https://github.com/openclaw/openclaw/pull/123>

Nunca imprima segredos. Use links Markdown seguros para Discord. Se não for publicado (ignorado/bloqueado), inclua o motivo.

Variáveis de Ambiente Esperadas do Agente

• $release-private: Caminho para o arquivo de estado/hotfix privado do Tideclaw.
• $TIDECLAW_DISCORD_TOKEN: Token do bot Discord do Tideclaw.
• $TIDECLAW_GITHUB_TOKEN: Token GitHub para o Tideclaw.
• OPENCLAW_ALLOW_ROOT: Definido como 1 para execução de cron root quando necessário.