Vollständige Release-Validierung

Full Release Validation ist der übergeordnete Release-Ablauf: der zentrale manuelle Einstiegspunkt für Nachweise vor dem Release. Die meisten Arbeiten erfolgen in untergeordneten Workflows, sodass ein fehlgeschlagener Ausführungsknoten erneut ausgeführt werden kann, ohne den gesamten Release neu zu starten.

Führen Sie ihn von einer vertrauenswürdigen Workflow-Referenz aus, normalerweise main, und übergeben Sie den Release-Branch, das Tag oder den vollständigen Commit-SHA als ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable

provider akzeptiert außerdem anthropic oder minimax für das betriebssystemübergreifende Onboarding und den durchgängigen Agent-Durchlauf. Wiederverwendbare untergeordnete Jobs ermitteln die aufgerufene Workflow-Testumgebung aus job.workflow_repository und job.workflow_sha, während die Eingabe ref den zu testenden Kandidaten auswählt. Dadurch bleibt die aktuelle vertrauenswürdige Validierungslogik verfügbar, wenn ein älterer Release-Branch oder ein älteres Tag validiert wird.

Jeder gestartete untergeordnete Workflow muss denselben Workflow-SHA melden wie der übergeordnete Full Release Validation-Durchlauf. Wenn sich main zwischen dem Start des übergeordneten und der untergeordneten Workflows ändert, schlägt der übergeordnete Ablauf sicher fehl, selbst wenn der untergeordnete Workflow erfolgreich ist. Für einen unveränderlichen Nachweis für einen exakten Commit verwenden Sie pnpm ci:full-release --sha <target-sha>. Das Hilfsprogramm erstellt eine temporäre release-ci/*-Referenz, die auf den aktuellen vertrauenswürdigen Stand von origin/main fixiert ist, übergibt den Ziel- SHA ausschließlich als Kandidaten-ref, verwendet vorhandene strikte Nachweise für das exakte Ziel erneut und löscht die Referenz nach der Validierung. Übergeben Sie -f reuse_evidence=false, um einen neuen Durchlauf zu erzwingen, oder --workflow-sha <trusted-main-sha>, um einen älteren Workflow-Commit auszuwählen, der vom aktuellen origin/main weiterhin erreichbar ist. Der Workflow selbst erstellt oder aktualisiert niemals Repository-Referenzen.

release_profile=stable und release_profile=full führen immer den umfassenden Live-/Docker-Dauertest aus. Übergeben Sie run_release_soak=true, um dieselben Dauertest-Lanes mit dem Profil beta einzuschließen. Die stabile Veröffentlichung lehnt ein Validierungsmanifest ohne diesen Dauertest und blockierende Nachweise zur Produktleistung ab.

Die Paketabnahme erstellt normalerweise den Kandidaten-Tarball aus der aufgelösten ref, einschließlich vollständiger SHA-Durchläufe, die mit pnpm ci:full-release gestartet wurden. Übergeben Sie nach einer Beta-Veröffentlichung release_package_spec=openclaw@YYYY.M.PATCH-beta.N, um das veröffentlichte npm-Paket für Release-Prüfungen, Paketabnahme, betriebssystemübergreifende Prüfungen, den Docker-Release-Pfad und Paket-Telegram wiederzuverwenden. Verwenden Sie package_acceptance_package_spec nur, wenn die Paketabnahme absichtlich ein anderes Paket prüfen soll. Die Live-Paket-Lane des Codex-Plugins folgt demselben Zustand: Veröffentlichte release_package_spec-Werte leiten codex_plugin_spec=npm:@openclaw/codex@<version> ab; SHA-/Artefakt-Durchläufe paketieren extensions/codex aus der ausgewählten Referenz; und Bediener können codex_plugin_spec direkt für Plugin-Quellen vom Typ npm:, npm-pack: oder git: festlegen. Die Lane erteilt die für dieses Plugin erforderliche ausdrückliche Genehmigung zur Installation der Codex CLI, führt anschließend die Vorabprüfung der Codex CLI und OpenAI-Agent-Durchläufe in derselben Sitzung aus.

Übergeordnete Phasen

Für rerun_group=all wird zuerst der Job Check for reusable validation evidence ausgeführt: Er sucht nach der neuesten vorherigen erfolgreichen vollständigen Validierung für exakt denselben Ziel-SHA, dasselbe Release-Profil, dieselbe effektive Dauertest-Einstellung und dieselben Validierungseingaben. Wenn solche Nachweise vorhanden sind, werden alle Lanes übersprungen, und die übergeordnete Prüfkomponente prüft erneut das unveränderliche übergeordnete Artefakt, die untergeordneten Durchläufe und die Startprotokolle. Dies dient ausschließlich der Wiederherstellung bei einer erneuten Ausführung desselben Kandidaten; eine Wiederverwendung über verschiedene SHAs hinweg wird dadurch nicht autorisiert. Führen Sie bei einem geänderten Kandidaten jedes Paket-, Artefakt-, Installations-, Docker- oder Provider- Gate erneut aus, das von dieser Änderung betroffen ist. Übergeben Sie reuse_evidence=false, um einen neuen vollständigen Durchlauf zu erzwingen. Die Wiederverwendung von Nachweisen erfolgt nur von main oder einer kanonischen, auf einen SHA fixierten release-ci/*-Referenz, deren Workflow-Commit weiterhin zur vertrauenswürdigen main-Abstammung gehört; andere Workflow-Referenzen führen die ausgewählten Lanes neu aus.

Ebenfalls für rerun_group=all erstellt der Job Verify Docker runtime image assets das Docker-Ziel runtime-assets mit OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Er läuft parallel zu den anderen Phasen und wird durch die übergeordnete Prüfkomponente erzwungen; die Lanes warten nicht mehr auf ihn, bevor sie gestartet werden. Eine engere rerun_group überspringt diese Vorabprüfung.

Der übergeordnete Ablauf startet die Produktleistungsprüfung immer im reinen Artefaktmodus. OpenClaw Performance erlaubt die Veröffentlichung von Berichten nur für geplante Durchläufe oder einen manuellen Start, bei dem ausdrücklich publish_reports=true festgelegt ist. Die Schutzprüfung für den reinen Artefaktmodus muss erfolgreich abgeschlossen werden und nachweisen, dass der Veröffentlichungsjob übersprungen blieb. Neue und wiederverwendete Nachweise zeichnen controls.performanceReportPublication=artifact-only auf; die Prüfkomponente und die Auswahl für die Wiederverwendung lehnen Nachweise ohne den entsprechenden normalisierten Nachweis des untergeordneten Leistungs-Workflows ab.

Die Prüfkomponente lädt das kanonische Manifest als full-release-validation-<run-id>-<run-attempt> hoch. Die Nachweiswerkzeuge validieren dessen Artefakt-ID, Digest, erzeugenden Durchlauf und Versuch, bevor sie exakt diese Artefakt-ID herunterladen. Sie begrenzen die Größe der heruntergeladenen ZIP-Datei, prüfen deren Bytes anhand des REST- sha256:-Digest und lesen den einzigen zulässigen, größenbeschränkten Manifesteintrag als Datenstrom, ohne das Archiv zu extrahieren. Ein Alias mit stabilem Namen bleibt vorübergehend für ältere Veröffentlichungsnutzer bestehen. Die Prüfkomponente bevorzugt immer das versuchsqualifizierte Artefakt; übergangsweise akzeptiert sie den stabilen Namen nur für einen Manifest-v2-Erzeuger im ersten Versuch. Für spätere Versuche und Manifest v3 lehnt sie diesen veralteten Namen ab.

Für ref=main mit rerun_group=all, für release/*-Referenzen und für Tideclaw- Alpha-Referenzen ersetzt ein neuerer übergeordneter Durchlauf einen älteren mit derselben Referenz und Gruppe zur erneuten Ausführung. Wenn der übergeordnete Durchlauf abgebrochen wird, bricht dessen Überwachung alle bereits gestarteten untergeordneten Workflows ab. Validierungsdurchläufe für Tags und fixierte SHAs brechen einander nicht ab.

Phasen der Release-Prüfungen

OpenClaw Release Checks ist der größte untergeordnete Workflow. Er löst das Ziel einmal auf und bereitet ein gemeinsames Artefakt release-package-under-test vor, wenn paket- oder Docker-bezogene Phasen es benötigen.

Docker-Blöcke des Release-Pfads

Die Phase des Docker-Release-Pfads führt diese Blöcke aus, wenn live_suite_filter leer ist:

Verwenden Sie im wiederverwendbaren Live-/E2E-Workflow gezielt docker_lanes=<lane[,lane]>, wenn nur ein Docker-Testlauf fehlgeschlagen ist. Die Release-Artefakte enthalten, sofern verfügbar, für jeden Testlauf Wiederholungsbefehle mit Eingaben zur Wiederverwendung des Paketartefakts und Images.

Release-Profile

release_profile steuert hauptsächlich den Umfang der Live-/Provider-Abdeckung innerhalb der Release-Prüfungen. Es entfernt weder die normale vollständige CI noch Plugin-Vorabveröffentlichung, Installations-Smoke-Test, Paketakzeptanz oder QA Lab. Die Profile stable und full führen stets eine umfassende Repo-/Live- E2E-Abdeckung sowie Dauerprüfungen des Docker-Release-Pfads aus. Das Profil beta kann diese mit run_release_soak=true aktivieren. Die Paketakzeptanz stellt für jeden vollständigen Kandidaten den kanonischen Paket- Telegram-E2E-Test bereit, sodass der übergeordnete Workflow diesen Live-Poller nicht dupliziert.

Nur in full enthaltene Ergänzungen

Diese Testsuiten werden von stable übersprungen und sind in full enthalten:

stable enthält native-live-src-gateway-profiles-anthropic-smoke und native-live-src-gateway-profiles-opencode-go-smoke; full verwendet stattdessen die breiter angelegten Anthropic- und OpenCode-Go-Modell-Shards. Gezielte Wiederholungen können weiterhin die zusammengefassten Handles native-live-src-gateway-profiles-anthropic oder native-live-src-gateway-profiles-opencode-go verwenden.

Gezielte Wiederholungen

Verwenden Sie rerun_group, um die Wiederholung nicht betroffener Release-Umgebungen zu vermeiden:

Verwenden Sie live_suite_filter mit rerun_group=live-e2e, wenn eine einzelne Live-Testsuite fehlgeschlagen ist. Gültige Filter-IDs sind im wiederverwendbaren Live-/E2E-Workflow definiert, darunter docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker und live-codex-harness-docker.

Das Handle live-gateway-advisory-docker ist ein zusammengefasstes Wiederholungs-Handle für seine drei Provider-Shards und verzweigt daher weiterhin auf alle informativen Docker-Gateway-Jobs.

Verwenden Sie cross_os_suite_filter mit rerun_group=cross-os, wenn eine einzelne betriebssystemübergreifende Lane fehlgeschlagen ist. Der Filter akzeptiert eine Betriebssystem-ID, eine Testsuite-ID oder ein Betriebssystem-/Testsuite-Paar, zum Beispiel windows/packaged-upgrade, windows oder packaged-fresh. Betriebssystemübergreifende Zusammenfassungen enthalten phasenbezogene Zeitangaben für Lanes mit Paket-Upgrade, und lang laufende Befehle geben Heartbeat-Zeilen aus, sodass eine blockierte Aktualisierung bereits vor dem Job-Zeitlimit sichtbar ist.

Fehler bei QA-Release-Prüfungen blockieren die normale Release-Validierung. Die Prüfung der QA-Laufzeit-Tool-Abdeckung (dynamische Tool-Abweichung zwischen openclaw und codex in der Standardstufe) blockiert ebenfalls die Verifizierung der Release-Prüfungen, obwohl die zugrunde liegende QA-Laufzeitparitäts-Lane informativ ist. Tideclaw-Alpha-Läufe können Release-Prüfungs-Lanes, die nicht die Paketsicherheit betreffen, weiterhin als informativ behandeln. Bei release_profile=beta sind die Live-Provider-Testsuiten der Validierung Run repo/live E2E validation informativ: Modellbereitstellungen von Drittanbietern ändern sich unabhängig von einem Release, daher weist beta auf deren Fehler als Warnungen hin, während die Profile stable und full sie weiterhin als blockierend behandeln. Wenn live_suite_filter ausdrücklich eine geschützte QA-Live-Lane wie Discord, WhatsApp oder Slack anfordert, muss die entsprechende Repo-Variable OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED aktiviert sein; andernfalls schlägt die Eingabeerfassung fehl, anstatt die Lane stillschweigend zu überspringen. Führen Sie rerun_group=qa, qa-parity oder qa-live erneut aus, wenn Sie aktuelle QA-Nachweise benötigen.

Aufzubewahrende Nachweise

Bewahren Sie die Zusammenfassung Full Release Validation als Index auf Release-Ebene auf. Sie verknüpft die IDs der untergeordneten Läufe und enthält Tabellen mit den langsamsten Jobs. Untersuchen Sie bei Fehlern zuerst den untergeordneten Workflow und führen Sie anschließend das kleinste passende Handle von oben erneut aus.

Nützliche Artefakte:

• release-package-under-test aus OpenClaw Release Checks
• Artefakte des Docker-Release-Pfads unter .artifacts/docker-tests/
• package-under-test der Paketakzeptanz und Docker-Akzeptanzartefakte
• Artefakte der betriebssystemübergreifenden Release-Prüfungen für jedes Betriebssystem und jede Testsuite
• Artefakte für QA-Parität, Laufzeitparität, Matrix und Telegram

Workflow-Dateien

• .github/workflows/full-release-validation.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-live-and-e2e-checks-reusable.yml
• .github/workflows/plugin-prerelease.yml
• .github/workflows/install-smoke.yml
• .github/workflows/install-smoke-reusable.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-performance.yml
• .github/workflows/npm-telegram-beta-e2e.yml