OpenClaw-Mac-Release

OpenClaw Mac Release

Verwenden mit $release-openclaw-maintainer, $release-openclaw-ci, $one-password und $release-private, falls vorhanden, wenn stabile macOS-Assets, Release-Ops-Mac-Preflight, Notarisierung, Appcast-Promotion oder Mac-Release-Wiederherstellung beteiligt sind.

Dies ist ein reguläres Stable-Release-Skill. Rufen Sie es nicht für Extended-Stable auf; der GitHub-Release dieses Tracks trägt gemeinsame Validierungsnachweise, erbt jedoch keine macOS-Assets oder Appcast-Promotion.

Release-Autorisierung

Eine explizite Stable- oder Full-Release-Anforderung schließt die macOS-Veröffentlichung ein, es sei denn, der Operator schränkt deren Umfang ein. Setzen Sie die Validierung, Signierung, Notarisierung, Promotion und Verifizierung fort, ohne separate macOS-Zustimmung einzuholen. Bewahren Sie die exakte Release-Identität und alle Artefaktprüfungen. Die macOS-Veröffentlichung läuft parallel zu npm und blockiert diese nie; ein macOS-Fehler hält weder den npm/ClawHub-Release, die GitHub-Release-Finalisierung noch den Hauptabschluss auf. Beheben Sie ihn parallel.

Befolgen Sie die aktuell vom Besitzer konfigurierte Umgebungsrichtlinie. Erfinden Sie keine zusätzliche Prüferanforderung und stellen Sie keine veraltete wieder her. Wenn GitHub noch eine Genehmigung erzwingt, melden Sie die tatsächliche Regel und lösen Sie sie über den Besitzer; Richtlinienänderungen erfordern explizite Anweisung des Organisationsbesitzers und verifizierte aktive Admin-Mitgliedschaft. Geben Sie niemals vor, ein Prüfer zu sein, fabrizieren Sie keine Genehmigung und verwenden Sie keinen anderen Signierungspfad, um eine erzwungene Regel zu umgehen.

Anmeldeinformationen

• Lösen Sie Peter-eigene ASC-Item-Referenzen, Schlüssel-IDs, Aussteller-IDs und Service-Token-Herkunft aus $release-private.
• Felder: private_key_p8, key_id, issuer_id.
• Symptom für abgelaufenen/zurückgezogenen Schlüssel: xcrun notarytool submit schlägt fehl mit HTTP status code: 401. Unauthenticated.
• Validieren Sie Kandidaten-ASC-Anmeldeinformationen mit xcrun notarytool history, bevor Sie GitHub-Secrets setzen.

1Password

• Verwenden Sie $one-password: alle op-Arbeiten in einer einzigen persistenten tmux-Sitzung, keine geheime Ausgabe.
• Verwenden Sie die Service-Token-Anleitung aus $release-private, sofern verfügbar.
• Wenn ein Service-Token fehlschlägt, führen Sie nur Statusprüfungen durch: Token vorhanden/Länge und op whoami; niemals Token-Werte ausgeben.
• Wenn Desktop-App-Authentifizierung erforderlich ist, aber Touch ID nicht verfügbar ist, setzen Sie OP_BIOMETRIC_UNLOCK_ENABLED=false für den manuellen op account add --signin-Pfad.

GitHub Secrets

Ziel-Release-Ops-Repository-Umgebung: openclaw/releases, env mac-release.

Setzen Sie nur nach lokaler Notar-Authentifizierungsvalidierung:

• APP_STORE_CONNECT_API_KEY_P8
• APP_STORE_CONNECT_KEY_ID
• APP_STORE_CONNECT_ISSUER_ID

Aktualisieren Sie diese nicht aus gemischten Quellen. Alle drei ASC-Felder müssen aus demselben 1Password-Eintrag stammen.

Workflow-Form

• openclaw/openclaw ist das öffentliche Produkt-Repository. Seine GitHub Releases-Seite ist der Ort, an dem macOS-Assets schließlich angehängt werden.
• openclaw/openclaw macos-release.yml ist nur eine öffentliche Übergabe-Validierung. Es signiert, notarisiert oder lädt niemals macOS-Assets hoch, unabhängig von preflight_only.
• openclaw/releases ist das eingeschränkte Release-Ops-Repository. Seine macOS-Workflows signieren, notarisieren, validieren und promoten Assets auf den openclaw/openclaw GitHub-Release.
• Der öffentliche Release-Branch kann Mac-spezifische Paketkorrekturen enthalten, nachdem der Stable-Tag/npm bereits live ist.
• Verwenden Sie source_ref=release/YYYY.M.PATCH für Release-Ops-Mac-Preflight/Validierung, wenn Sie diese Branch-Variation erstellen.
• Behalten Sie tag=vYYYY.M.PATCH bei, das auf den ursprünglichen Stable-Release-Commit zeigt.
• Echte Mac-Veröffentlichung muss wiederverwenden:
  • einen erfolgreichen Release-Ops-Mac-Preflight-Lauf für denselben Tag/dieselbe Source-SHA
  • einen erfolgreichen Release-Ops-Mac-Validierungslauf für denselben Tag/dieselbe Source-SHA
• Release-Ops-Preflight und echte Veröffentlichung verwenden die mac-release-Umgebung für Signierungs- und Promotionsgeheimnisse und deren Main-Only-Deployment-Richtlinie. Der autorisierte Release-Operator arbeitet unter den aktuellen Regeln dieser Umgebung weiter.
• Wenn die Preflight-Source-SHA von der Tag-SHA abweicht, muss die Validierung ebenfalls dieselbe source_ref verwenden; die Promotion lehnt nicht übereinstimmende Nachweise ab.

Notarisierung

• OpenClaw verwendet scripts/notarize-mac-artifact.sh.
• xcrun notarytool submit sollte --no-s3-acceleration verwenden; beschleunigtes Hochladen kann irreführende 401-Fehler verursachen, selbst wenn notarytool history erfolgreich ist.
• Wenn die Signierung erfolgreich ist, die Notarisierung jedoch sofort mit 401 fehlschlägt, überprüfen Sie zuerst die Frische des ASC-Schlüssels.
• Wenn die Notarisierung nach dem Schreiben der Schlüsseldatei mehrere Minuten lang in Bearbeitung bleibt, ist dies die normale Apple-Wartezeit; bearbeiten Sie nicht blind.

Dispatch

Der öffentliche Übergabe-Workflow validiert Tag, Quelle, Build und Paketmetadaten vor der Veröffentlichung. Er erfordert keine GitHub-Release-Seite, da er keine Assets hochlädt. Behalten Sie diese Validierung vor dem echten Publikations-Workflow bei. Der Kern-Publisher besitzt die GitHub-Release-Finalisierung; die macOS-Promotion hängt ihre verifizierten Assets an diesen Release an, unabhängig ob er noch ein Entwurf oder bereits öffentlich ist, sodass nie auf den npm-Umschalter gewartet wird.

Öffentliche Übergabe-Validierung:

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

• Verwenden Sie den öffentlichen Release-Branch als Workflow-Ref, sodass die Actions-Liste release/YYYY.M.PATCH anzeigt, passend zu vorherigen stabilen macOS-Übergabeläufen.
• Verwenden Sie nicht --ref main oder --ref vYYYY.M.PATCH für diese öffentliche Übergabe-Validierung. Der Workflow checkt den Tag intern aus dem tag-Eingabefeld aus.

Release-Ops-Preflight:

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

Verfolgen Sie den Lauf durch Signierung und Notarisierung unter der konfigurierten Umgebungsrichtlinie. Notieren Sie die erfolgreiche Preflight-Lauf-ID; eine Genehmigungspause ist kein erfolgreicher Preflight.

Fortsetzung ist die Standardeinstellung. Das erneute Auslösen desselben Preflight-Befehls nach einem Fehler (Notary-Ausfall, DMG-Paketierung, Collector) setzt jede Variante vom neuesten Prüfpunkt fort, der von einem fehlgeschlagenen oder abgebrochenen main-Dispatch für denselben Tag und dieselbe Source-SHA hinterlassen wurde; nur Varianten ohne Prüfpunkt werden neu erstellt. Das Laufprotokoll gibt Resuming <variant> from run <id> attempt <n> oder Building <variant> aus. ignore_checkpoints=true erzwingt frische Builds. Übergeben Sie resume_notarization_run_id, resume_notarization_run_attempt und resume_notarization_variant nur, um einen bestimmten Lauf festzulegen, oder für Prüfpunkte, die vor der Existenz des Fortsetzungsindex erstellt wurden (macos-resume-<tag>-<variant>-<sha>-Artefakte). Bevorzugen Sie gh run rerun <run-id> --failed --repo openclaw/releases, wenn der fehlgeschlagene Job noch im aktuellen Lauf ist.

Release-Ops-Validierung für einen Branch-Variation-Preflight:

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

Notieren Sie die erfolgreiche Validierungs-Lauf-ID.

Echte Veröffentlichung:

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

Verfolgen Sie die Promotion durch Asset-Upload und Appcast-Veröffentlichung unter derselben Release-Autorisierung und aktuellen Umgebungsrichtlinie.

• Release-Ops openclaw/releases Publikations-/Validierungs-Workflows laufen von ihrer eigenen vertrauenswürdigen main-Workflow-Ref. Die echte Veröffentlichung hat eine Absicherung, die jede andere Workflow-Ref ablehnt. Diese angezeigte main-Ref ist erwartet; die öffentliche OpenClaw-Quelle wird durch tag und optional source_ref ausgewählt.

Überprüfen

• gh release view vYYYY.M.PATCH --repo openclaw/openclaw zeigt zip, dmg, dSYM zip; sobald der npm-Publisher es umgeschaltet hat: nicht Entwurf, nicht Pre-Release.
• Öffentliches main appcast.xml zeigt auf OpenClaw-YYYY.M.PATCH.zip.
• Appcast-Eintrag hat sparkle:version, sparkle:shortVersionString, Länge und sparkle:edSignature.