Vollständige Release-Validierung

Full Release Validation ist der übergreifende Rahmen für die Produktvalidierung von Releases. Die meisten Arbeiten finden in untergeordneten Workflows statt, sodass eine fehlgeschlagene Box erneut ausgeführt werden kann, ohne den gesamten Release neu zu starten. Führen Sie die Release-Vorbereitung aus, bevor Sie den Code-SHA fixieren; sie aktualisiert die Gebietsschema-Ausgabe der Control UI, wenn der Hintergrund-Bot sie noch nicht übernommen hat, und erzwingt anschließend dieselbe strikte Prüfung auf null Fallbacks, die auch von der Release-CI verwendet wird.

Fixieren Sie den produktseitig vollständigen Commit vor dem Changelog als Code-SHA und führen Sie dann Folgendes aus:

pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

provider akzeptiert außerdem anthropic oder minimax für das Betriebssystem-übergreifende Onboarding und den End-to-End-Agentendurchlauf. Das Hilfsprogramm leitet das Profil beta aus Alpha-/Beta- Paketversionen ab und verwendet andernfalls stable. Übergeben Sie alternative Workflow-Eingaben mit -f key=value; verwenden Sie -f release_profile=full nur für die umfassende Advisory-Prüfung.

Das Hilfsprogramm erstellt eine temporäre release-ci/*-Referenz, die auf genau einen vertrauenswürdigen origin/main-Workflow-SHA festgelegt ist, übergibt den Ziel-SHA ausschließlich als Kandidaten-ref und löscht die temporäre Referenz nach der Validierung. Jeder ausgelöste untergeordnete Workflow muss denselben Workflow-SHA melden. Übergeben Sie -f reuse_evidence=false, um eine neue Ausführung zu erzwingen, oder --workflow-sha <trusted-main-sha>, um einen älteren Workflow-Commit auszuwählen, der weiterhin vom aktuellen origin/main aus erreichbar ist. Der Workflow selbst erstellt oder aktualisiert niemals Repository-Referenzen.

Ausnahme für Extended-Stable

Die Veröffentlichung von Extended-Stable erfordert eine Ausführung, bei der sowohl Workflow als auch Ziel dem kanonischen Branch entsprechen:

gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

Verwenden Sie weder pnpm ci:full-release noch release-ci/*. Die Veröffentlichung bindet den Branch der Ausführung, den Head-/Ziel-SHA, das Manifest workflowRef, die ID und den Versuch an den kanonischen Branch und den Release-Commit.

Portieren Sie Produktfehler zurück; nehmen Sie für Werkzeuge mit fixiertem Ziel die kleinste verhaltensbewahrende Korrektur vor; wiederholen Sie Provider-, Genehmigungs- oder Runner-Fehler ohne Quellcodeänderung. Jede Branch-Änderung erfordert eine vollständig neue Ausführung. Lassen Sie erforderliches Paket-, Installer-, Update-, Kanal- oder Live-Verhalten nicht aus, nur weil das Ziel alt ist.

Wenn der Code-SHA für einen regulären Release grün ist, generieren und committen Sie ausschließlich CHANGELOG.md. Dieser neue Commit ist der Release-SHA. Führen Sie dasselbe Hilfsprogramm für den Release-SHA aus. Produktnachweise werden nur wiederverwendet, wenn GitHub nachweist, dass der Release- SHA vom Code-SHA abstammt und die vollständige Menge geänderter Pfade exakt CHANGELOG.md entspricht; npm-Preflight und Paket-/Installationsakzeptanz werden dennoch auf dem Release-SHA ausgeführt.

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

Package Acceptance erstellt den Kandidaten-Tarball normalerweise aus dem aufgelösten ref, einschließlich vollständiger SHA-Ausführungen, die mit pnpm ci:full-release ausgelöst 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, Package Acceptance, Betriebssystem-übergreifende Prüfungen, den Docker-Release-Pfad und Paket-Telegram wiederzuverwenden. Verwenden Sie package_acceptance_package_spec nur, wenn Package Acceptance absichtlich ein anderes Paket nachweisen 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-Ausführungen packen extensions/codex aus der ausgewählten Referenz; und Operatoren können codex_plugin_spec direkt für Plugin-Quellen vom Typ npm:, npm-pack: oder git: festlegen. Die Lane erteilt die von diesem Plugin benötigte ausdrückliche Genehmigung zur Installation der Codex CLI und führt anschließend den Codex-CLI-Preflight sowie OpenAI-Agentendurchläufe in derselben Sitzung aus. Ihr abschließender Durchlauf ohne Wiederholungen und mit mittlerer Denktiefe sendet sichtbaren Fortschritt mit ausgelassenem Codex-final, liest zufällig erzeugte Workspace-Eingaben, schreibt deren exaktes Artefakt und sendet einen ausdrücklichen Abschluss. Dadurch wird die Regression in v2026.7.1 erkannt, bei der das Senden eines gewöhnlichen Fortschritts den Durchlauf beendete.

Phasen der obersten Ebene

Für rerun_group=all wird zuerst ein Check for reusable validation evidence-Job ausgeführt. Er sucht nach der neuesten vorherigen erfolgreichen vollständigen Validierung mit demselben Release- Profil, derselben effektiven Dauertest-Einstellung und denselben Validierungseingaben. Wiederholungen für exakt dasselbe Ziel verwenden exact-target-full-validation-v1. Ein Nachfolger, dessen vollständiges Delta exakt CHANGELOG.md entspricht, verwendet changelog-only-release-v1; jede Produkt-Lane wird übersprungen und der Verifizierer prüft unabhängig den GitHub-Commit-Vergleich, das unveränderliche übergeordnete Artefakt, die untergeordneten Ausführungen und die Auslösungsprotokolle erneut. Jede andere Zieländerung erfordert eine neue Code-SHA-Validierung. Übergeben Sie reuse_evidence=false, um eine neue vollständige Ausführung zu erzwingen. Die Wiederverwendung von Nachweisen erfolgt nur aus main oder einer kanonischen, 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.

Eine neue paketbezogene Validierung bereitet einen unveränderlichen Tarball und ein Docker- Image-Artefakt vor, bevor Plugin Prerelease und OpenClaw Release Checks ausgelöst werden. Beide untergeordneten Workflows prüfen vor der Verwendung denselben Paket-SHA, dieselben Artefakt-IDs und Dienst-Digests, denselben Versuch der erzeugenden Ausführung sowie denselben Digest des Docker-Archivs. Die paketunabhängige reine Docker-Schicht verwendet einen inhaltsadressierten GHCR-Cache; kandidatenspezifische Images bleiben unveränderliche GitHub-Artefakte. Fokussierte Ausführungen mit einer ausdrücklich veröffentlichten Paketspezifikation behalten stattdessen den bestehenden Paketpfad bei.

Ebenfalls für rerun_group=all erstellt ein Verify Docker runtime image assets-Job das Docker-Ziel runtime-assets mit OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Er wird parallel zu den anderen Phasen ausgeführt und vom übergreifenden Verifizierer erzwungen; Lanes warten vor dem Auslösen nicht mehr auf ihn. Ein enger gefasster rerun_group überspringt diesen Preflight.

Der übergreifende Workflow löst die Produktleistung stets im reinen Artefaktmodus aus. OpenClaw Performance erlaubt die Veröffentlichung von Berichten nur für geplante Ausführungen oder eine manuelle Auslösung, die ausdrücklich publish_reports=true festlegt. Der Schutz für den reinen Artefaktmodus muss erfolgreich abgeschlossen werden und damit nachweisen, dass der Publisher-Job übersprungen blieb. Neue und wiederverwendete Nachweise zeichnen controls.performanceReportPublication=artifact-only auf; der Verifizierer und die Auswahl für die Wiederverwendung lehnen Nachweise ohne den entsprechenden normalisierten Nachweis des untergeordneten Leistungs-Workflows ab.

Der Verifizierer lädt das kanonische Manifest als full-release-validation-<run-id>-<run-attempt> hoch. Die Nachweis-Tools validieren dessen Artefakt-ID, Digest, erzeugenden Lauf und Versuch, bevor sie genau diese Artefakt-ID herunterladen. Sie begrenzen die Größe der heruntergeladenen ZIP-Datei, prüfen deren Bytes anhand des REST- sha256:-Digests und streamen den einzigen zulässigen, größenbeschränkten Manifesteintrag, ohne das Archiv zu extrahieren. Ein Alias mit stabilem Namen bleibt vorübergehend für ältere Veröffentlichungs-Consumer bestehen. Der Verifizierer bevorzugt stets das versuchsqualifizierte Artefakt; während der Übergangsphase akzeptiert er den stabilen Namen nur für einen Manifest-v2- Producer bei Versuch 1. Für spätere Versuche und Manifest v3 lehnt er diesen Legacy-Namen ab.

Für ref=main mit rerun_group=all, für release/*-Refs und für Tideclaw- Alpha-Refs ersetzt ein neuerer übergeordneter Lauf einen älteren mit demselben Ref und derselben Wiederholungslaufgruppe. Wenn der übergeordnete Lauf abgebrochen wird, bricht dessen Monitor alle untergeordneten Workflows ab, die er bereits gestartet hat. Tag- und angeheftete-SHA-Validierungsläufe brechen einander nicht ab.

Phasen der Release-Prüfungen

OpenClaw Release Checks ist der größte untergeordnete Workflow. Er löst das Ziel einmalig auf und validiert das gemeinsame Paketartefakt des übergeordneten Workflows, sofern verfügbar. Ein direkter oder fokussierter Dispatch erstellt sein eigenes release-package-under-test- Artefakt, wenn paket- oder Docker-bezogene Phasen es benötigen.

Docker-Release-Pfad-Blöcke

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

Verwenden Sie gezielt docker_lanes=<lane[,lane]> im wiederverwendbaren Live-/E2E-Workflow, wenn nur eine Docker-Lane fehlgeschlagen ist. Die Release-Artefakte enthalten für jede Lane Befehle zur erneuten Ausführung mit Eingaben zur Wiederverwendung von Paketartefakten und Images, sofern verfügbar.

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-Prerelease, Installations-Smoke-Test, Paketabnahme oder QA Lab. Stabile und vollständige Profile führen immer eine umfassende repo-/livebezogene E2E- und Docker-Release-Pfad-Dauertestabdeckung aus. Das Beta-Profil kann diese mit run_release_soak=true aktivieren. Die Paketabnahme stellt für jeden vollständigen Kandidaten den kanonischen Paket-Telegram-E2E-Test bereit, sodass der übergeordnete Workflow diesen Live-Poller nicht dupliziert.

Nur bei vollständigen Profilen enthaltene Ergänzungen

Diese Suites werden von stable übersprungen und von full einbezogen:

stable enthält native-live-src-gateway-profiles-anthropic-smoke und native-live-src-gateway-profiles-opencode-go-smoke; full verwendet stattdessen die breiteren Anthropic- und OpenCode-Go-Modell-Shards. Gezielte erneute Ausführungen können weiterhin die aggregierten Handles native-live-src-gateway-profiles-anthropic oder native-live-src-gateway-profiles-opencode-go verwenden.

Gezielte erneute Ausführungen

Verwenden Sie rerun_group, um die Wiederholung nicht zugehöriger Release-Umgebungen zu vermeiden:

Verwenden Sie live_suite_filter mit rerun_group=live-e2e, wenn eine Live-Suite 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.

Legen Sie für eine gezielte erneute Ausführung eines QA-Transports rerun_group=qa-live fest und verwenden Sie den kanonischen Selektor qa-live-matrix, qa-live-telegram, qa-live-discord, qa-live-whatsapp oder qa-live-slack.

Das Handle live-gateway-advisory-docker ist ein aggregiertes Handle zur erneuten Ausführung seiner drei Provider-Shards und verteilt sich daher weiterhin auf alle beratenden Docker-Gateway-Jobs.

Verwenden Sie cross_os_suite_filter mit rerun_group=cross-os, wenn eine betriebssystemübergreifende Lane fehlgeschlagen ist. Der Filter akzeptiert eine Betriebssystem-ID, eine Suite-ID oder ein Betriebssystem-/Suite-Paar, beispielsweise windows/packaged-upgrade, windows oder packaged-fresh. Betriebssystemübergreifende Zusammenfassungen enthalten phasenbezogene Zeitangaben für paketierte Upgrade-Lanes, und lang laufende Befehle geben Heartbeat-Zeilen aus, sodass eine festhängende Aktualisierung vor dem Job-Timeout sichtbar wird.

Fehler bei QA-Release-Prüfungen blockieren die normale Release-Validierung nur für ausgewählte Abdeckungs-Lanes der Matrix-, Telegram- und QA-Laufzeit-Tools. QA-Parität, Laufzeitparität und die zugangsgesteuerten Live-Lanes für Discord, WhatsApp und Slack sind beratend und veröffentlichen Statusartefakte, ohne den Release-Prüfer zu blockieren. Tideclaw- Alpha-Ausführungen können Release-Prüfungs-Lanes, die nicht die Paketsicherheit betreffen, weiterhin als beratend behandeln. Mit release_profile=beta sind die Live-Provider-Suites Run repo/live E2E validation beratend: Bereitstellungen von Drittanbieter-Modellen ändern sich während eines Releases, daher stellt Beta deren Fehler als Warnungen dar, während stabile und vollständige Profile sie weiterhin blockierend behandeln. Wenn live_suite_filter ausdrücklich eine zugangsgesteuerte 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, statt 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 verlinkt die IDs untergeordneter Ausführungen und enthält Tabellen der langsamsten Jobs. Untersuchen Sie bei Fehlern zuerst den untergeordneten Workflow und führen Sie anschließend das kleinste passende Handle oben erneut aus.

Dokumentieren Sie für ein reguläres Release sowohl den Code-SHA als auch den Release-SHA, die Wiederverwendungsrichtlinie und die Menge geänderter Pfade, die erfolgreiche übergeordnete Ausführung des Code-SHA sowie die leichtgewichtige übergeordnete Ausführung des Release-SHA. Dokumentieren Sie für Extended Stable den kanonischen Branch, den exakten Release- SHA, die ID und den Versuch der neuen übergeordneten Ausführung, die Workflow-Referenz, jede untergeordnete Ausführung sowie jede Kompatibilitätsreparatur des eingefrorenen Ziels oder beabsichtigte Auslassung.

Nützliche Artefakte:

• release-package-under-test aus OpenClaw Release Checks
• Docker-Release-Pfad-Artefakte unter .artifacts/docker-tests/
• Paketabnahme package-under-test und Docker-Abnahmeartefakte
• Betriebssystemübergreifende Release-Prüfungsartefakte für jedes Betriebssystem und jede Suite
• QA-Parität, Laufzeitparität und ausgewählte Artefakte für Matrix, Telegram, Discord, WhatsApp, oder Slack

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