Release-Richtlinie

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• stable: getaggte Releases, die standardmäßig in npm beta veröffentlichen, oder in npm latest, wenn dies ausdrücklich angefordert wird
• beta: Vorab-Release-Tags, die in npm beta veröffentlichen
• dev: der bewegliche Head von main

​

Versionsbenennung

• Stable-Release-Version: YYYY.M.D
  • Git-Tag: vYYYY.M.D
• Stable-Korrektur-Release-Version: YYYY.M.D-N
  • Git-Tag: vYYYY.M.D-N
• Beta-Vorab-Release-Version: YYYY.M.D-beta.N
  • Git-Tag: vYYYY.M.D-beta.N
• Monat oder Tag nicht mit führenden Nullen auffüllen
• latest bedeutet den aktuell promoteten stabilen npm-Release
• beta bedeutet das aktuelle Beta-Installationsziel
• Stable- und Stable-Korrektur-Releases veröffentlichen standardmäßig in npm beta; Release-Operatoren können ausdrücklich latest als Ziel wählen oder später einen geprüften Beta-Build promoten
• Jeder stabile OpenClaw-Release liefert das npm-Paket und die macOS-App gemeinsam aus; Beta-Releases validieren und veröffentlichen normalerweise zuerst den npm-/Paketpfad, während macOS-App-Build, Signierung und Notarisierung für stabile Releases reserviert sind, sofern nicht ausdrücklich angefordert

​

Release-Takt

• Releases durchlaufen zuerst Beta
• Stable folgt erst, nachdem die neueste Beta validiert wurde
• Maintainer erstellen Releases normalerweise aus einem release/YYYY.M.D-Branch, der aus dem aktuellen main erstellt wurde, damit Release-Validierung und Fixes neue Entwicklung auf main nicht blockieren
• Wenn ein Beta-Tag gepusht oder veröffentlicht wurde und einen Fix benötigt, erstellen Maintainer das nächste -beta.N-Tag, statt das alte Beta-Tag zu löschen oder neu zu erstellen
• Detailliertes Release-Verfahren, Freigaben, Zugangsdaten und Wiederherstellungshinweise sind nur für Maintainer bestimmt

​

Checkliste für Release-Operatoren

1. Vom aktuellen main starten: neuesten Stand pullen, bestätigen, dass der Ziel-Commit gepusht ist, und bestätigen, dass die aktuelle main-CI ausreichend grün ist, um davon zu branchen.
2. Den obersten Abschnitt in CHANGELOG.md anhand der echten Commit-Historie mit /changelog neu schreiben, Einträge benutzerorientiert halten, committen, pushen und vor dem Branching noch einmal rebasen/pullen.
3. Release-Kompatibilitätsdatensätze in src/plugins/compat/registry.ts und src/commands/doctor/shared/deprecation-compat.ts prüfen. Abgelaufene Kompatibilität nur entfernen, wenn der Upgrade-Pfad weiterhin abgedeckt bleibt, oder dokumentieren, warum sie absichtlich beibehalten wird.
4. release/YYYY.M.D aus dem aktuellen main erstellen; normale Release-Arbeiten nicht direkt auf main durchführen.
5. Jede erforderliche Versionsstelle für das beabsichtigte Tag erhöhen, dann pnpm release:prep ausführen. Dies aktualisiert Plugin-Versionen, Plugin-Inventar, Konfigurationsschema, gebündelte Channel-Konfigurationsmetadaten, Konfigurationsdokumentations-Baseline, Plugin SDK Exporte und Plugin SDK API-Baseline in der richtigen Reihenfolge. Jegliche generierte Drift vor dem Taggen committen. Dann den lokalen deterministischen Preflight ausführen: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build und pnpm release:check.
6. OpenClaw NPM Release mit preflight_only=true ausführen. Bevor ein Tag existiert, ist ein vollständiger 40-Zeichen-SHA des Release-Branch für rein validierenden Preflight zulässig. Die erfolgreiche preflight_run_id speichern.
7. Alle Pre-Release-Tests mit Full Release Validation für den Release-Branch, das Tag oder den vollständigen Commit-SHA starten. Dies ist der eine manuelle Einstiegspunkt für die vier großen Release-Testboxen: Vitest, Docker, QA Lab und Package.
8. Wenn die Validierung fehlschlägt, auf dem Release-Branch fixen und die kleinste fehlgeschlagene Datei, Lane, Workflow-Job, Paketprofil, Provider- oder Modell-Allowlist erneut ausführen, die den Fix belegt. Den vollständigen Umbrella nur erneut ausführen, wenn die geänderte Oberfläche frühere Nachweise veraltet macht.
9. Für Beta vYYYY.M.D-beta.N taggen, dann OpenClaw Release Publish aus dem passenden release/YYYY.M.D-Branch ausführen. Es prüft pnpm plugins:sync:check, dispatcht alle veröffentlichbaren Plugin-Pakete an npm und dieselbe Menge parallel an ClawHub und promotet dann das vorbereitete OpenClaw-npm-Preflight-Artefakt mit dem passenden Dist-Tag, sobald die Plugin-npm-Veröffentlichung erfolgreich ist. Nachdem das OpenClaw-npm-Publish-Child erfolgreich ist, erstellt oder aktualisiert es die passende GitHub-Release-/Prerelease-Seite aus dem vollständigen passenden Abschnitt in CHANGELOG.md. Stable-Releases, die in npm latest veröffentlicht werden, werden zum neuesten GitHub-Release; stabile Wartungs-Releases, die auf npm beta bleiben, werden mit GitHub latest=false erstellt. Die ClawHub-Veröffentlichung kann noch laufen, während OpenClaw npm veröffentlicht, aber der Release-Publish-Workflow gibt die Child-Run-IDs sofort aus. Standardmäßig wartet er nach dem Dispatch nicht auf ClawHub, damit die OpenClaw-npm-Verfügbarkeit nicht durch langsamere ClawHub-Freigaben oder Registry-Arbeiten blockiert wird; setzen Sie wait_for_clawhub=true, wenn ClawHub den Workflow-Abschluss blockieren muss. Der ClawHub-Pfad wiederholt vorübergehende Fehler bei der Installation von CLI-Abhängigkeiten, veröffentlicht Plugins mit bestandenem Preview auch dann, wenn eine Preview-Zelle flakt, und endet mit Registry-Verifizierung für jede erwartete Plugin-Version, sodass Teilveröffentlichungen sichtbar und wiederholbar bleiben. Nach der Veröffentlichung ausführen: pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> um GitHub-Prerelease, npm-beta-Dist-Tags, npm-Integrität, veröffentlichten Installationspfad, exakte ClawHub-Versionen, ClawHub-Artefakte und Child- Workflow-Ergebnisse mit einem Befehl zu verifizieren. --rerun-failed-clawhub hinzufügen, wenn der ClawHub-Sidecar nur in wiederholbaren Jobs fehlgeschlagen ist und direkt erneut ausgeführt werden soll. Dann die Post-Publish-Package-Acceptance gegen das veröffentlichte Paket openclaw@YYYY.M.D-beta.N oder openclaw@beta ausführen. Wenn ein gepushter oder veröffentlichter Prerelease einen Fix benötigt, die nächste passende Prerelease-Nummer erstellen; den alten Prerelease nicht löschen oder umschreiben.
10. Für Stable nur fortfahren, nachdem die geprüfte Beta oder der Release Candidate die erforderlichen Validierungsnachweise hat. Stable-npm-Veröffentlichung läuft ebenfalls über OpenClaw Release Publish, wobei das erfolgreiche Preflight-Artefakt über preflight_run_id wiederverwendet wird; Stable-macOS-Release-Bereitschaft erfordert außerdem die paketierten .zip, .dmg, .dSYM.zip und die aktualisierte appcast.xml auf main. Der private macOS-Publish-Workflow veröffentlicht den signierten Appcast automatisch auf dem öffentlichen main, nachdem Release-Assets verifiziert wurden; wenn Branch-Schutz den direkten Push blockiert, öffnet oder aktualisiert er einen Appcast-PR.
11. Nach der Veröffentlichung den npm-Post-Publish-Verifizierer, bei Bedarf optionales eigenständiges veröffentlichtes-npm-Telegram-E2E für Post-Publish-Channel-Nachweis, Dist-Tag-Promotion bei Bedarf, die generierte GitHub-Release-Seite verifizieren und die Schritte für die Release-Ankündigung ausführen.

​

Release-Preflight

• Führen Sie pnpm check:test-types vor dem Release-Preflight aus, damit Test-TypeScript auch außerhalb des schnelleren lokalen pnpm check-Gates abgedeckt bleibt
• Führen Sie pnpm check:architecture vor dem Release-Preflight aus, damit die breiteren Prüfungen auf Importzyklen und Architekturgrenzen außerhalb des schnelleren lokalen Gates grün sind
• Führen Sie pnpm build && pnpm ui:build vor pnpm release:check aus, damit die erwarteten dist/*-Release-Artefakte und das Control-UI-Bundle für den Pack- Validierungsschritt vorhanden sind
• Führen Sie pnpm release:prep nach dem Versionsbump im Root und vor dem Tagging aus. Es führt jeden deterministischen Release-Generator aus, der nach einer Versions-/Konfigurations-/API-Änderung häufig driftet: Plugin-Versionen, Plugin-Inventar, Basiskonfigurations- schema, gebündelte Channel-Konfigurationsmetadaten, Konfigurationsdokumentations-Baseline, Plugin-SDK- Exporte und Plugin-SDK-API-Baseline. pnpm release:check führt diese Guards im Prüfmodus erneut aus und meldet jeden gefundenen Driftfehler generierter Dateien in einem Durchlauf, bevor Paket-Release-Prüfungen ausgeführt werden.
• Führen Sie den manuellen Full Release Validation-Workflow vor der Release-Freigabe aus, um alle Pre-Release-Testboxen über einen einzigen Einstiegspunkt zu starten. Er akzeptiert einen Branch, Tag oder vollständigen Commit-SHA, dispatcht manuelle CI und dispatcht OpenClaw Release Checks für Installations-Smoke, Paketakzeptanz, Cross-OS- Paketprüfungen, QA-Lab-Parität, Matrix- und Telegram-Lanes. Stabile/Standardläufe behalten erschöpfende Live-/E2E- und Docker-Release-Pfad-Soak-Prüfungen hinter run_release_soak=true; release_profile=full erzwingt Soak. Mit release_profile=full und rerun_group=all läuft außerdem Paket-Telegram- E2E gegen das release-package-under-test-Artefakt aus den Release-Prüfungen. Geben Sie release_package_spec nach der Veröffentlichung einer Beta an, um das ausgelieferte npm-Paket über Release-Prüfungen, Package Acceptance und Paket-Telegram- E2E hinweg wiederzuverwenden, ohne den Release-Tarball neu zu bauen. Geben Sie npm_telegram_package_spec nur an, wenn Telegram ein anderes veröffentlichtes Paket als der Rest der Release-Validierung verwenden soll. Geben Sie package_acceptance_package_spec an, wenn Package Acceptance ein anderes veröffentlichtes Paket als die Release-Paketspezifikation verwenden soll. Geben Sie evidence_package_spec an, wenn der private Evidenzbericht nachweisen soll, dass die Validierung einem veröffentlichten npm-Paket entspricht, ohne Telegram E2E zu erzwingen. Beispiel: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• Führen Sie den manuellen Package Acceptance-Workflow aus, wenn Sie einen Side-Channel-Nachweis für einen Paketkandidaten möchten, während die Release-Arbeit weiterläuft. Verwenden Sie source=npm für openclaw@beta, openclaw@latest oder eine exakte Release-Version; source=ref, um einen vertrauenswürdigen package_ref-Branch/-Tag/-SHA mit dem aktuellen workflow_ref-Harness zu packen; source=url für einen HTTPS-Tarball mit erforderlichem SHA-256; oder source=artifact für einen Tarball, der von einem anderen GitHub- Actions-Lauf hochgeladen wurde. Der Workflow löst den Kandidaten zu package-under-test auf, verwendet den Docker-E2E-Release-Scheduler gegen diesen Tarball wieder und kann Telegram-QA gegen denselben Tarball mit telegram_mode=mock-openai oder telegram_mode=live-frontier ausführen. Wenn die ausgewählten Docker-Lanes published-upgrade-survivor enthalten, ist das Paket- artefakt der Kandidat und published_upgrade_survivor_baseline wählt die veröffentlichte Baseline aus. update-restart-auth verwendet das Kandidatenpaket als sowohl installierte CLI als auch package-under-test, damit der verwaltete Neustartpfad des Update-Befehls des Kandidaten geprüft wird. Beispiel: gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai Häufige Profile:
  • smoke: Installations-/Channel-/Agent-, Gateway-Netzwerk- und Konfigurations-Neulade-Lanes
  • package: artefaktnative Paket-/Update-/Neustart-/Plugin-Lanes ohne OpenWebUI oder live ClawHub
  • product: Paketprofil plus MCP-Kanäle, Cron-/Subagent-Bereinigung, OpenAI-Websuche und OpenWebUI
  • full: Docker-Release-Pfad-Chunks mit OpenWebUI
  • custom: exakte docker_lanes-Auswahl für einen fokussierten erneuten Lauf
• Führen Sie den manuellen CI-Workflow direkt aus, wenn Sie nur vollständige normale CI- Abdeckung für den Release-Kandidaten benötigen. Manuelle CI-Dispatches umgehen Changed- Scoping und erzwingen die Linux-Node-Shards, Bundled-Plugin-Shards, Channel- Contracts, Node-22-Kompatibilität, check, check-additional, Build-Smoke, Docs-Prüfungen, Python-Skills, Windows, macOS, Android und Control-UI-i18n- Lanes. Beispiel: gh workflow run ci.yml --ref release/YYYY.M.D
• Führen Sie pnpm qa:otel:smoke aus, wenn Sie Release-Telemetrie validieren. Es führt QA-Lab über einen lokalen OTLP/HTTP-Empfänger aus und verifiziert die exportierten Trace- Span-Namen, begrenzten Attribute und Inhalts-/Kennungs-Redaktion, ohne Opik, Langfuse oder einen anderen externen Collector zu benötigen.
• Führen Sie pnpm release:check vor jedem getaggten Release aus
• Führen Sie OpenClaw Release Publish für die verändernde Publish-Sequenz aus, nachdem der Tag existiert. Dispatchen Sie ihn von release/YYYY.M.D (oder main, wenn ein von main erreichbarer Tag veröffentlicht wird), übergeben Sie den Release-Tag und die erfolgreiche OpenClaw-npm- preflight_run_id, und behalten Sie den standardmäßigen Plugin-Publish-Scope all-publishable bei, es sei denn, Sie führen bewusst eine fokussierte Reparatur aus. Der Workflow serialisiert Plugin-npm-Publish, Plugin-ClawHub-Publish und OpenClaw- npm-Publish, damit das Core-Paket nicht vor seinen externalisierten Plugins veröffentlicht wird.
• Release-Prüfungen laufen jetzt in einem separaten manuellen Workflow: OpenClaw Release Checks
• OpenClaw Release Checks führt vor der Release-Freigabe außerdem die QA-Lab-Mock-Paritätslane plus das schnelle Live-Matrix-Profil und die Telegram-QA-Lane aus. Die Live- Lanes verwenden die qa-live-shared-Umgebung; Telegram verwendet außerdem Convex-CI- Credential-Leases. Führen Sie den manuellen QA-Lab - All Lanes-Workflow mit matrix_profile=all und matrix_shards=true aus, wenn Sie vollständigen Matrix- Transport sowie Medien- und E2EE-Inventar parallel möchten.
• Cross-OS-Installations- und Upgrade-Laufzeitvalidierung ist Teil der öffentlichen OpenClaw Release Checks und Full Release Validation, die den wiederverwendbaren Workflow .github/workflows/openclaw-cross-os-release-checks-reusable.yml direkt aufrufen
• Diese Aufteilung ist beabsichtigt: Halten Sie den echten npm-Release-Pfad kurz, deterministisch und artefaktfokussiert, während langsamere Live-Prüfungen in ihrer eigenen Lane bleiben, damit sie den Publish nicht verzögern oder blockieren
• Release-Prüfungen mit Secrets sollten über Full Release Validation oder über die main-/Release-Workflow-Ref dispatcht werden, damit Workflow-Logik und Secrets kontrolliert bleiben
• OpenClaw Release Checks akzeptiert einen Branch, Tag oder vollständigen Commit-SHA, solange der aufgelöste Commit von einem OpenClaw-Branch oder Release-Tag erreichbar ist
• Die validierungsreine Preflight-Prüfung von OpenClaw NPM Release akzeptiert außerdem den aktuellen vollständigen 40-Zeichen-Commit-SHA des Workflow-Branches, ohne einen gepushten Tag zu verlangen
• Dieser SHA-Pfad dient nur der Validierung und kann nicht zu einem echten Publish hochgestuft werden
• Im SHA-Modus synthetisiert der Workflow v<package.json version> nur für die Paketmetadatenprüfung; echter Publish erfordert weiterhin einen echten Release-Tag
• Beide Workflows halten den echten Publish- und Promotion-Pfad auf GitHub-gehosteten Runnern, während der nicht verändernde Validierungspfad die größeren Blacksmith-Linux-Runner verwenden kann
• Dieser Workflow führt OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache mit den Workflow-Secrets OPENAI_API_KEY und ANTHROPIC_API_KEY aus
• npm-Release-Preflight wartet nicht mehr auf die separate Release-Prüfungs-Lane
• Bevor Sie einen Release-Kandidaten lokal taggen, führen Sie RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check aus. Der Helper führt die schnellen Release-Guardrails, Plugin-npm-/ClawHub-Release-Prüfungen, Build, UI-Build und release:openclaw:npm:check in der Reihenfolge aus, die häufige freigabeblockierende Fehler abfängt, bevor der GitHub-Publish-Workflow startet.
• Führen Sie RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (oder den passenden Beta-/Korrektur-Tag) vor der Freigabe aus
• Führen Sie nach dem npm-Publish node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (oder die passende Beta-/Korrekturversion) aus, um den veröffentlichten Registry- Installationspfad in einem frischen temporären Prefix zu verifizieren
• Führen Sie nach einem Beta-Publish OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live aus, um Onboarding mit installiertem Paket, Telegram-Einrichtung und echtes Telegram-E2E gegen das veröffentlichte npm-Paket über den gemeinsam geleasten Telegram-Credential- Pool zu verifizieren. Lokale einmalige Maintainer-Läufe können die Convex-Variablen weglassen und die drei OPENCLAW_QA_TELEGRAM_*-Env-Credentials direkt übergeben.
• Um den vollständigen Post-Publish-Beta-Smoke von einer Maintainer-Maschine aus auszuführen, verwenden Sie pnpm release:beta-smoke -- --beta betaN. Der Helper führt Parallels-npm-Update-/Fresh-Target-Validierung aus, dispatcht NPM Telegram Beta E2E, pollt den exakten Workflow-Lauf, lädt das Artefakt herunter und gibt den Telegram-Bericht aus.
• Maintainer können dieselbe Post-Publish-Prüfung über den manuellen Workflow NPM Telegram Beta E2E aus GitHub Actions ausführen. Er ist bewusst nur manuell und läuft nicht bei jedem Merge.
• Maintainer-Release-Automatisierung verwendet jetzt Preflight-dann-Promotion:
  • Echter npm-Publish muss eine erfolgreiche npm-preflight_run_id bestehen
  • Der echte npm-Publish muss vom selben main- oder release/YYYY.M.D-Branch dispatcht werden wie der erfolgreiche Preflight-Lauf
  • Stabile npm-Releases verwenden standardmäßig beta
  • Stabile npm-Publishs können über Workflow-Eingabe explizit latest anvisieren
  • Tokenbasierte npm-dist-tag-Mutation liegt jetzt in openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml aus Sicherheitsgründen, weil npm dist-tag add weiterhin NPM_TOKEN benötigt, während das öffentliche Repo bei OIDC-only-Publish bleibt
  • Öffentliches macOS Release ist validierungsrein; wenn ein Tag nur auf einem Release-Branch existiert, der Workflow aber von main dispatcht wird, setzen Sie public_release_branch=release/YYYY.M.D
  • Echter privater Mac-Publish muss erfolgreiche private Mac- preflight_run_id und validate_run_id bestehen
  • Die echten Publish-Pfade promoten vorbereitete Artefakte, statt sie erneut neu zu bauen
• Bei stabilen Korrektur-Releases wie YYYY.M.D-N prüft der Post-Publish-Verifizierer außerdem denselben Temp-Prefix-Upgrade-Pfad von YYYY.M.D auf YYYY.M.D-N, damit Release-Korrekturen ältere globale Installationen nicht unbemerkt auf dem stabilen Basis-Payload belassen können
• npm-Release-Preflight schlägt geschlossen fehl, wenn der Tarball nicht sowohl dist/control-ui/index.html als auch einen nicht leeren dist/control-ui/assets/-Payload enthält, damit wir nicht erneut ein leeres Browser-Dashboard ausliefern
• Die Post-Publish-Verifizierung prüft außerdem, dass veröffentlichte Plugin-Entrypoints und Paketmetadaten im installierten Registry-Layout vorhanden sind. Ein Release, das fehlende Plugin-Laufzeit-Payloads ausliefert, schlägt im Postpublish-Verifizierer fehl und kann nicht zu latest promotet werden.
• pnpm test:install:smoke erzwingt außerdem das npm-Pack-unpackedSize-Budget für den Kandidaten-Update-Tarball, damit Installer-E2E versehentliche Pack-Aufblähung vor dem Release-Publish-Pfad abfängt
• Wenn die Release-Arbeit CI-Planung, Extension-Timing-Manifeste oder Extension-Testmatrizen berührt hat, regenerieren und prüfen Sie die plannerverwalteten plugin-prerelease-extension-shard-Matrix-Ausgaben aus .github/workflows/plugin-prerelease.yml vor der Freigabe, damit Release Notes kein veraltetes CI-Layout beschreiben
• Die Bereitschaft stabiler macOS-Releases umfasst außerdem die Updater-Oberflächen:
  • Das GitHub-Release muss am Ende die gepackte .zip, .dmg und .dSYM.zip enthalten
  • appcast.xml auf main muss nach dem Publish auf das neue stabile Zip zeigen; der private macOS-Publish-Workflow committet es automatisch oder öffnet einen Appcast- PR, wenn direkter Push blockiert ist
  • Die gepackte App muss eine Nicht-Debug-Bundle-ID, eine nicht leere Sparkle-Feed- URL und eine CFBundleVersion auf oder über dem kanonischen Sparkle-Build-Floor für diese Release-Version behalten

​

Release-Testboxen

pnpm ci:full-release --sha <full-sha>

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N

• minimum: schnellster release-kritischer OpenAI-/Core-Live- und Docker-Pfad
• stable: Minimum plus stabile Provider-/Backend-Abdeckung für die Release-Freigabe
• full: Stable plus breite Advisory-Provider-/Medienabdeckung

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \
  -f npm_telegram_provider_mode=mock-openai

​

Vitest

• Full Release Validation-Zusammenfassung mit der URL des gestarteten CI-Laufs
• grüner CI-Lauf auf der exakten Ziel-SHA
• fehlgeschlagene oder langsame Shard-Namen aus den CI-Jobs bei der Untersuchung von Regressionen
• Vitest-Timing-Artefakte wie .artifacts/vitest-shard-timings.json, wenn ein Lauf eine Performance-Analyse benötigt

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

​

Docker

• vollständiger Install-Smoke mit aktiviertem langsamem globalem Bun-Install-Smoke
• Vorbereitung/Wiederverwendung des Root-Dockerfile-Smoke-Images nach Ziel-SHA, mit QR-, Root-/Gateway- und Installer-/Bun-Smoke-Jobs als separate Install-Smoke- Shards
• Repository-E2E-Lanes
• Release-Pfad-Docker-Chunks: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g und plugins-runtime-install-h
• OpenWebUI-Abdeckung innerhalb des Chunks plugins-runtime-services, wenn angefordert
• aufgeteilte Install-/Uninstall-Lanes für gebündelte Plugins bundled-plugin-install-uninstall-0 bis bundled-plugin-install-uninstall-23
• Live-/E2E-Provider-Suites und Docker-Live-Modellabdeckung, wenn Release-Prüfungen Live-Suites enthalten

​

QA Lab

• Mock-Parity-Lane, die die OpenAI-Candidate-Lane mit der Opus-4.6- Baseline mithilfe des agentischen Parity-Packs vergleicht
• schnelles Live-Matrix-QA-Profil mit der Umgebung qa-live-shared
• Live-Telegram-QA-Lane mit Convex-CI-Credential-Leases
• pnpm qa:otel:smoke, wenn Release-Telemetrie expliziten lokalen Nachweis benötigt

​

Package

• source=npm: openclaw@beta, openclaw@latest oder eine exakte OpenClaw-Release- Version
• source=ref: einen vertrauenswürdigen package_ref-Branch, -Tag oder vollständige Commit-SHA mit dem ausgewählten workflow_ref-Harness packen
• source=url: eine HTTPS-.tgz mit erforderlichem package_sha256 herunterladen
• source=artifact: eine von einem anderen GitHub-Actions-Lauf hochgeladene .tgz wiederverwenden

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

• smoke: schnelle Lanes für Paketinstallation/Kanal/Agent, Gateway-Netzwerk und erneutes Laden der Konfiguration
• package: Verträge für Installations-/Update-/Neustart-/Plugin-Paket plus Live-Nachweis der ClawHub-Skill-Installation; dies ist der Standard für Release-Prüfungen
• product: package plus MCP-Kanäle, Cron-/Subagent-Bereinigung, OpenAI-Websuche und OpenWebUI
• full: Docker-Release-Pfad-Chunks mit OpenWebUI
• custom: exakte docker_lanes-Liste für fokussierte Wiederholungen

​

Release-Veröffentlichungsautomatisierung

1. Release-Tag auschecken und dessen Commit-SHA auflösen.
2. Prüfen, dass der Tag von main oder release/* erreichbar ist.
3. pnpm plugins:sync:check ausführen.
4. Plugin NPM Release mit publish_scope=all-publishable und ref=<release-sha> auslösen.
5. Plugin ClawHub Release mit demselben Scope und derselben SHA auslösen.
6. OpenClaw NPM Release mit Release-Tag, npm-Dist-Tag und gespeichertem preflight_run_id auslösen.

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest

​

NPM-Workflow-Eingaben

• tag: erforderlicher Release-Tag wie v2026.4.2, v2026.4.2-1 oder v2026.4.2-beta.1; wenn preflight_only=true, darf dies auch die aktuelle vollständige 40-stellige Commit-SHA des Workflow-Branches für einen nur validierenden Preflight sein
• preflight_only: true nur für Validierung/Build/Paket, false für den echten Veröffentlichungspfad
• preflight_run_id: im echten Veröffentlichungspfad erforderlich, damit der Workflow den vorbereiteten Tarball aus dem erfolgreichen Preflight-Lauf wiederverwendet
• npm_dist_tag: npm-Ziel-Tag für den Veröffentlichungspfad; Standard ist beta

• tag: erforderlicher Release-Tag; muss bereits existieren
• preflight_run_id: erfolgreiche OpenClaw NPM Release-Preflight-Lauf-ID; erforderlich, wenn publish_openclaw_npm=true
• npm_dist_tag: npm-Ziel-Tag für das OpenClaw-Paket
• plugin_publish_scope: Standard ist all-publishable; verwenden Sie selected nur für fokussierte Reparaturarbeiten
• plugins: durch Kommas getrennte @openclaw/*-Paketnamen, wenn plugin_publish_scope=selected
• publish_openclaw_npm: Standard ist true; setzen Sie dies nur auf false, wenn Sie den Workflow als reinen Plugin-Reparatur-Orchestrator verwenden
• wait_for_clawhub: Standard ist false, damit die npm-Verfügbarkeit nicht durch den ClawHub-Sidecar blockiert wird; setzen Sie dies nur auf true, wenn der Workflow-Abschluss den ClawHub-Abschluss einschließen muss

• ref: Branch, Tag oder vollständige Commit-SHA zur Validierung. Prüfungen mit Secrets erfordern, dass der aufgelöste Commit von einem OpenClaw-Branch oder Release-Tag erreichbar ist.
• run_release_soak: entscheidet sich für vollständige Live-/E2E-, Docker- Release-Pfad- und All-Since-Upgrade-Survivor-Soak-Tests bei stabilen/ Standard-Release-Prüfungen. Wird durch release_profile=full erzwungen.

• Stabile Tags und Korrektur-Tags dürfen entweder nach beta oder latest veröffentlicht werden
• Beta-Prerelease-Tags dürfen nur nach beta veröffentlicht werden
• Für OpenClaw NPM Release ist die Eingabe einer vollständigen Commit-SHA nur erlaubt, wenn preflight_only=true
• OpenClaw Release Checks und Full Release Validation sind immer nur Validierung
• Der echte Veröffentlichungspfad muss denselben npm_dist_tag verwenden, der während des Preflights verwendet wurde; der Workflow prüft diese Metadaten, bevor die Veröffentlichung fortgesetzt wird

​

Stabile npm-Release-Sequenz

1. Führen Sie OpenClaw NPM Release mit preflight_only=true aus
   • Bevor ein Tag existiert, dürfen Sie die aktuelle vollständige Commit-SHA des Workflow-Branches für einen nur validierenden Probelauf des Preflight-Workflows verwenden
2. Wählen Sie npm_dist_tag=beta für den normalen Beta-First-Ablauf oder latest nur, wenn Sie bewusst eine direkte stabile Veröffentlichung möchten
3. Führen Sie Full Release Validation auf dem Release-Branch, Release-Tag oder der vollständigen Commit-SHA aus, wenn Sie normale CI plus Live-Prompt-Cache, Docker, QA Lab, Matrix und Telegram-Abdeckung aus einem manuellen Workflow möchten
4. Wenn Sie bewusst nur den deterministischen normalen Testgraphen benötigen, führen Sie stattdessen den manuellen CI-Workflow auf der Release-Ref aus
5. Speichern Sie den erfolgreichen preflight_run_id
6. Führen Sie OpenClaw Release Publish mit demselben tag, demselben npm_dist_tag und dem gespeicherten preflight_run_id aus; es veröffentlicht externalisierte Plugins in npm und ClawHub, bevor das OpenClaw-npm-Paket promoted wird
7. Wenn das Release auf beta gelandet ist, verwenden Sie den privaten openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml- Workflow, um diese stabile Version von beta nach latest zu promoten
8. Wenn das Release bewusst direkt nach latest veröffentlicht wurde und beta sofort demselben stabilen Build folgen soll, verwenden Sie denselben privaten Workflow, um beide Dist-Tags auf die stabile Version zeigen zu lassen, oder lassen Sie die geplante Selbstheilungs-Synchronisierung beta später verschieben

​

Öffentliche Referenzen

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

​

Verwandt

• Release-Kanäle