release-openclaw-mac

OpenClaw Mac Release

Use com $release-openclaw-maintainer, $release-openclaw-ci, $one-password e $release-private se existir quando ativos macOS estáveis, pré-verificação de release-ops, notarização, promoção de appcast ou recuperação de release macOS estiverem envolvidos.

Esta é uma skill de release estável regular. Não a invoque para extended-stable; o GitHub Release dessa trilha carrega evidência de validação compartilhada, mas não herda ativos macOS ou promoção de appcast.

Autorização de release

Uma solicitação explícita de release estável ou completa inclui a publicação macOS, a menos que o operador limite seu escopo. Continue pela validação, assinatura, notarização, promoção e verificação sem pedir consentimento separado para macOS. Mantenha a identidade exata da release e todas as verificações de artefatos. A publicação macOS é executada em paralelo com npm e nunca a bloqueia; uma falha no macOS não segura a release npm/ClawHub, a finalização do GitHub Release ou o fechamento principal. Corrija em paralelo.

Siga a política de ambiente configurada pelo proprietário atual. Não invente um requisito extra de revisor ou recrie um obsoleto. Se o GitHub ainda impuser uma aprovação, reporte a regra real e resolva-a através de seu proprietário; mudanças de política exigem direção explícita do proprietário da organização e associação de administrador ativa verificada. Nunca se passe por um revisor, fabrique aprovação ou use outro caminho de assinatura para contornar uma regra imposta.

Credenciais

• Resolva referências de itens ASC (App Store Connect) de propriedade de Peter, IDs de chave, IDs de emissor e proveniência de token de serviço a partir de $release-private.
• Campos: private_key_p8, key_id, issuer_id.
• Sintoma de chave obsoleta/revogada: xcrun notarytool submit falha com HTTP status code: 401. Unauthenticated.
• Valide credenciais ASC candidatas com xcrun notarytool history antes de definir segredos do GitHub.

1Password

• Use $one-password: todo trabalho op dentro de uma única sessão tmux persistente, sem saída de segredos.
• Use a orientação de token de serviço de $release-private quando disponível.
• Se um token de serviço falhar, execute verificações apenas de status: token presente/comprimento e op whoami; nunca imprima valores de token.
• Se a autenticação do aplicativo de desktop for necessária, mas o Touch ID estiver indisponível, defina OP_BIOMETRIC_UNLOCK_ENABLED=false para o caminho manual op account add --signin.

Segredos do GitHub

Ambiente do repositório de release-ops alvo: openclaw/releases, env mac-release.

Defina apenas após validação local de autenticação notary:

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

Não atualize estes a partir de fontes mistas. Todos os três campos ASC devem vir do mesmo item do 1Password.

Forma do Workflow

• openclaw/openclaw é o repositório público do produto. Sua página de GitHub Releases é onde os ativos macOS são finalmente anexados.
• openclaw/openclaw macos-release.yml é apenas validação pública de passagem. Nunca assina, notariza ou faz upload de ativos macOS, independentemente de preflight_only.
• openclaw/releases é o repositório restrito de release-ops. Seus workflows macOS assinam, notarizam, validam e promovem ativos para o release do GitHub openclaw/openclaw.
• A branch de release pública pode carregar correções de empacotamento exclusivas do macOS após a tag estável/npm já estarem ativos.
• Use source_ref=release/YYYY.M.PATCH para preflight/validação macOS de release-ops ao construir essa variação de branch.
• Mantenha tag=vYYYY.M.PATCH apontando para o commit original da release estável.
• A publicação real do macOS deve reutilizar:
  • uma execução bem-sucedida de preflight macOS de release-ops para a mesma tag/SHA de origem
  • uma execução bem-sucedida de validação macOS de release-ops para a mesma tag/SHA de origem
• O preflight e a publicação real do release-ops usam o ambiente mac-release para segredos de assinatura e promoção e sua política de implantação apenas em main. O operador de release autorizado continua sob as regras atuais desse ambiente.
• Se o SHA da fonte do preflight diferir do SHA da tag, a validação também deve usar o mesmo source_ref; a promoção rejeita prova incompatível.

Notarização

• OpenClaw usa scripts/notarize-mac-artifact.sh.
• xcrun notarytool submit deve usar --no-s3-acceleration; upload acelerado pode apresentar 401 enganosos mesmo quando notarytool history funciona.
• Se a assinatura for bem-sucedida, mas a notarização falhar imediatamente com 401, verifique primeiro a atualidade da chave ASC.
• Se a notarização permanecer em andamento por vários minutos após a escrita do arquivo de chave, isso é o tempo de espera normal da Apple; não edite cegamente.

Despacho

O workflow de validação pública verifica a tag, origem, build e metadados do pacote antes da publicação. Ele não requer uma página de GitHub Release porque não faz upload de ativos. Mantenha essa validação antes do workflow de publicação real. O editor principal detém a finalização do GitHub Release; a promoção macOS anexa seus ativos validados a esse release, seja ele ainda um rascunho ou já público, portanto nunca espera pela troca do npm.

Validação de entrega pública:

gh workflow run macos-release.yml --repo openclaw/openclaw \
  --ref release/YYYY.M.PATCH \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=true \
  -f public_release_branch=release/YYYY.M.PATCH

• Use a branch de release pública como ref do workflow para que a lista de Actions exiba release/YYYY.M.PATCH, correspondendo às execuções de entrega macOS estável anteriores.
• Não use --ref main ou --ref vYYYY.M.PATCH para essa validação de entrega pública. O workflow verifica a tag a partir da entrada tag internamente.

Preflight do release-ops:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH \
  -f preflight_only=true \
  -f smoke_test_only=false \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Acompanhe a execução até assinatura e notarização sob a política de ambiente configurada. Registre o ID da execução de preflight bem-sucedida; uma pausa de aprovação não é uma execução de preflight bem-sucedida.

Retomada é o padrão. Reenviar o mesmo comando de preflight após uma falha (indisponibilidade do notary, empacotamento DMG, coletor) retoma todas as variantes a partir do checkpoint mais recente deixado por um despacho main falho ou cancelado para a mesma tag e SHA de origem; apenas variantes sem um checkpoint reconstroem. O log da execução imprime Resuming <variante> from run <id> attempt <n> ou Building <variante>. ignore_checkpoints=true força builds novos. Passe resume_notarization_run_id, resume_notarization_run_attempt e resume_notarization_variant apenas para fixar uma execução específica, ou para checkpoints feitos antes da existência do índice de retomada (artefatos macos-resume-<tag>-<variant>-<sha>). Prefira gh run rerun <run-id> --failed --repo openclaw/releases quando o job falho ainda estiver na execução atual.

Validação do release-ops para um preflight de variação de branch:

gh workflow run openclaw-macos-validate.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f source_ref=release/YYYY.M.PATCH

Registre o ID da execução de validação bem-sucedida.

Publicação real:

gh workflow run openclaw-macos-publish.yml --repo openclaw/releases --ref main \
  -f tag=vYYYY.M.PATCH \
  -f preflight_only=false \
  -f smoke_test_only=false \
  -f preflight_run_id=<execucao-preflight-bem-sucedida> \
  -f validate_run_id=<execucao-validacao-bem-sucedida> \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Acompanhe a promoção até o upload de ativos e publicação do appcast sob a mesma autorização de release e política de ambiente atual.

• Os workflows de publicação/validação do release-ops openclaw/releases são executados a partir de seu próprio ref de workflow main confiável. A publicação real tem uma proteção que rejeita qualquer outro ref de workflow. Esse ref main exibido é esperado; a fonte pública do OpenClaw é selecionada por tag e source_ref opcional.

Verificar

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw mostra zip, dmg, zip dSYM; uma vez que o editor npm o tenha virado: não é rascunho, não é pré-release.
• appcast.xml do main público aponta para OpenClaw-YYYY.M.PATCH.zip.
• A entrada do appcast tem sparkle:version, sparkle:shortVersionString, tamanho e sparkle:edSignature.