release-openclaw-mac

Publication macOS OpenClaw

Utilisez avec $release-openclaw-maintainer, $release-openclaw-ci, $one-password, et $release-private si ce dernier existe lorsqu'il s'agit d'assets macOS stables, de prévol release-ops macOS, de notarisation, de promotion du fil d'actualité (appcast), ou de récupération de publication macOS.

Ceci est une compétence standard pour les versions stables. Ne l'invoquez pas pour une version étendue-stable ; la GitHub Release de ce canal transporte des preuves de validation partagées mais n'hérite pas des assets macOS ni de la promotion du fil d'actualité.

Autorisation de publication

Une demande explicite de version stable ou complète inclut la publication macOS, sauf si l'opérateur en limite la portée. Poursuivez la validation, la signature, la notarisation, la promotion et la vérification sans demander de consentement séparé pour macOS. Conservez l'identité exacte de la version et toutes les vérifications des artefacts. La publication macOS s'exécute en parallèle avec npm et ne la bloque jamais ; un échec macOS ne retient pas la version npm/ClawHub, la finalisation de la GitHub Release, ni la clôture principale. Corrigez-le en parallèle.

Suivez la politique d'environnement configurée par le propriétaire actuel. N'inventez pas d'exigence supplémentaire de relecture et ne recréez pas une exigence obsolète. Si GitHub impose toujours une approbation, signalez la règle réelle et résolvez-la via son propriétaire ; les changements de politique nécessitent une directive explicite du propriétaire de l'organisation et une appartenance admin active vérifiée. N'usurpez jamais l'identité d'un relecteur, ne fabriquez pas d'approbation, et n'utilisez pas un autre chemin de signature pour contourner une règle imposée.

Identifiants

• Résolvez les références d'éléments ASC appartenant à Peter, les identifiants de clés, les identifiants d'émetteur et la provenance des jetons de service à partir de $release-private.
• Champs : private_key_p8, key_id, issuer_id.
• Symptôme d'une clé périmée/révoquée : xcrun notarytool submit échoue avec HTTP status code: 401. Unauthenticated.
• Validez les identifiants ASC candidats avec xcrun notarytool history avant de définir les secrets GitHub.

1Password

• Utilisez $one-password : tout le travail op dans une seule session tmux persistante, aucune sortie secrète.
• Utilisez les directives de jeton de service de $release-private lorsqu'elles sont disponibles.
• Si un jeton de service échoue, exécutez des vérifications de statut uniquement : présence/longueur du jeton et op whoami ; n'imprimez jamais les valeurs des jetons.
• Si l'authentification par application de bureau est nécessaire mais que Touch ID est indisponible, définissez OP_BIOMETRIC_UNLOCK_ENABLED=false pour le chemin manuel op account add --signin.

Secrets GitHub

Environnement du dépôt release-ops cible : openclaw/releases, env mac-release.

Définissez uniquement après validation locale de l'authentification notary :

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

Ne mettez pas à jour ces valeurs à partir de sources mélangées. Les trois champs ASC doivent provenir du même élément 1Password.

Forme du workflow

• openclaw/openclaw est le dépôt public du produit. Sa page GitHub Releases est l'endroit où les assets macOS sont finalement attachés.
• openclaw/openclaw macos-release.yml est uniquement une validation de transfert public. Il ne signe, ne notarise ni ne télécharge jamais d'assets macOS, indépendamment de preflight_only.
• openclaw/releases est le dépôt restreint release-ops. Ses workflows macOS signent, notarisent, valident et promeuvent les assets sur la GitHub Release de openclaw/openclaw.
• La branche de publication publique peut contenir des correctifs de packaging spécifiques à macOS après que le tag stable/npm est déjà en ligne.
• Utilisez source_ref=release/YYYY.M.PATCH pour la prévalidation/validation macOS release-ops lors de la construction de cette variation de branche.
• Gardez tag=vYYYY.M.PATCH pointant vers le commit original de la version stable.
• La publication macOS réelle doit réutiliser :
  • une exécution réussie de la prévalidation macOS release-ops pour le même tag/SHA source
  • une exécution réussie de la validation macOS release-ops pour le même tag/SHA source
• La prévalidation et la publication réelle release-ops utilisent l'environnement mac-release pour les secrets de signature et de promotion et sa politique de déploiement réservée à la branche principale. L'opérateur de publication autorisé continue sous les règles actuelles de cet environnement.
• Si le SHA source de la prévalidation diffère du SHA du tag, la validation doit également utiliser le même source_ref ; la promotion rejette une preuve non correspondante.

Notarisation

• OpenClaw utilise scripts/notarize-mac-artifact.sh.
• xcrun notarytool submit doit utiliser --no-s3-acceleration ; un téléchargement accéléré peut faire apparaître des 401 trompeurs même si notarytool history réussit.
• Si la signature réussit mais que la notarisation échoue immédiatement avec 401, vérifiez d'abord la fraîcheur de la clé ASC.
• Si la notarisation reste en cours pendant plusieurs minutes après l'écriture du fichier de clé, il s'agit d'un temps d'attente normal d'Apple ; n'éditez pas aveuglément.

Envoi

Le workflow de transfert public valide le tag, la source, la construction et les métadonnées du package avant la publication. Il n'a pas besoin d'une page GitHub Release car il ne télécharge pas d'assets. Conservez cette validation avant le workflow de publication réel. L'éditeur principal possède la finalisation de la GitHub Release ; la promotion macOS attache ses assets vérifiés à cette version, qu'elle soit encore un brouillon ou déjà publique, donc elle n'attend jamais le basculement npm.

Validation de transfert public :

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

• Utilisez la branche de publication publique comme ref du workflow afin que la liste Actions affiche release/YYYY.M.PATCH, correspondant aux précédentes exécutions de transfert macOS stables.
• N'utilisez pas --ref main ou --ref vYYYY.M.PATCH pour cette validation de transfert public. Le workflow vérifie le tag à partir de l'entrée tag en interne.

Prévalidation 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

Suivez l'exécution à travers la signature et la notarisation sous la politique d'environnement configurée. Enregistrez l'identifiant de l'exécution réussie de la prévalidation ; une pause d'approbation n'est pas une prévalidation réussie.

La reprise est par défaut. Renvoyer la même commande de prévalidation après un échec (panne notary, packaging DMG, collecteur) reprend chaque variante à partir du point de contrôle le plus récent laissé par un envoi main échoué ou annulé pour le même tag et SHA source ; seules les variantes sans point de contrôle sont reconstruites. Le journal d'exécution affiche Resuming <variant> from run <id> attempt <n> ou Building <variant>. ignore_checkpoints=true force des constructions fraîches. Passez resume_notarization_run_id, resume_notarization_run_attempt, et resume_notarization_variant uniquement pour épingler une exécution spécifique, ou pour des points de contrôle effectués avant l'existence de l'index de reprise (artefacts macos-resume-<tag>-<variant>-<sha>). Préférez gh run rerun <run-id> --failed --repo openclaw/releases lorsque le job échoué est toujours dans l'exécution actuelle.

Validation release-ops pour une prévalidation de variation de branche :

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

Enregistrez l'identifiant de l'exécution réussie de la validation.

Publication réelle :

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=<successful-preflight-run> \
  -f validate_run_id=<successful-validation-run> \
  -f allow_late_calver_recovery=false \
  -f public_release_branch=release/YYYY.M.PATCH

Suivez la promotion à travers le téléchargement des assets et la publication du fil d'actualité sous la même autorisation de publication et la politique d'environnement actuelle.

• Les workflows de publication/validation release-ops openclaw/releases s'exécutent à partir de leur propre ref de workflow main de confiance. La publication réelle a une garde qui rejette toute autre ref de workflow. Cette ref main affichée est attendue ; la source publique OpenClaw est sélectionnée par tag et source_ref optionnel.

Vérifier

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw montre zip, dmg, dSYM zip ; une fois que l'éditeur npm a basculé : pas un brouillon, pas une pré-version.
• Le appcast.xml public main pointe vers OpenClaw-YYYY.M.PATCH.zip.
• L'entrée du fil d'actualité a sparkle:version, sparkle:shortVersionString, la longueur, et sparkle:edSignature.