Vollständige Release-Validierung

Full Release Validation ist der Release-Rahmen. Es ist der einzige manuelle Einstiegspunkt für den Pre-Release-Nachweis, aber die meiste Arbeit geschieht in untergeordneten Workflows, damit ein fehlgeschlagener Rechner 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 die vollständige 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

Untergeordnete Workflows verwenden die vertrauenswürdige Workflow-Referenz für das Test-Harness und die Eingabe ref für den zu testenden Kandidaten. Dadurch bleibt neue Validierungslogik verfügbar, wenn ein älterer Release-Branch oder ein älteres Tag validiert wird.

release_profile=stable und release_profile=full führen immer den vollständigen Live-/Docker-Dauerlauf aus. Übergeben Sie run_release_soak=true, um dieselben Dauerlauf-Lanes mit dem Beta-Profil einzubeziehen. Die Stable-Veröffentlichung weist ein Validierungsmanifest ohne diesen Dauerlauf und blockierende Nachweise zur Produktleistung zurück.

Package Acceptance baut das Kandidaten-Tarball normalerweise aus dem aufgelösten ref, einschließlich vollständiger SHA-Läufe, die mit pnpm ci:full-release ausgelöst wurden. Nach einer Beta-Veröffentlichung übergeben Sie release_package_spec=openclaw@YYYY.M.PATCH-beta.N, um das veröffentlichte npm-Paket über Release-Prüfungen, Package Acceptance, plattformübergreifende Prüfungen, Release-Pfad-Docker und Paket-Telegram hinweg 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-/Artefaktläufe 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: setzen. Die Lane erteilt die explizite Installationsgenehmigung für die Codex CLI, die dieses Plugin verlangt, und führt dann den Codex-CLI-Preflight sowie OpenAI-Agent-Turns in derselben Sitzung aus.

Top-Level-Phasen

Für ref=main und rerun_group=all ersetzt ein neuerer Rahmen einen älteren. Wenn der übergeordnete Lauf abgebrochen wird, bricht sein Monitor alle untergeordneten Workflows ab, die er bereits ausgelöst hat. Validierungsläufe für Release-Branches und Tags brechen sich standardmäßig nicht gegenseitig 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 für den Release-Pfad

Die Docker-Phase für den Release-Pfad 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 Befehle für erneute Läufe pro Lane mit Eingaben für Paketartefakt und Image-Wiederverwendung, sofern verfügbar.

Release-Profile

release_profile steuert hauptsächlich die Live-/Provider-Breite innerhalb der Release-Prüfungen. Es entfernt keine normale vollständige CI, Plugin Prerelease, Installations-Smoke, Paketabnahme oder QA Lab. Stabile und vollständige Profile führen immer umfassende Repo/Live-E2E- und Docker-Soak-Abdeckung für den Release-Pfad aus. Das Beta-Profil kann dies mit run_release_soak=true aktivieren. Paketabnahme liefert das kanonische Paket-Telegram-E2E für jeden vollständigen Kandidaten, daher dupliziert der Umbrella diesen Live-Poller nicht.

Nur in full 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. Fokussierte erneute Läufe können weiterhin die aggregierten Handles native-live-src-gateway-profiles-anthropic oder native-live-src-gateway-profiles-opencode-go verwenden.

Fokussierte erneute Läufe

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

Verwenden Sie live_suite_filter mit rerun_group=live-e2e, wenn eine Live-Suite fehlgeschlagen ist. Gültige Filter-IDs werden 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.

Der Handle live-gateway-advisory-docker ist ein aggregierter Rerun-Handle für seine drei Provider-Shards, sodass er weiterhin auf alle Advisory-Docker-Gateway-Jobs auffächert.

Verwenden Sie cross_os_suite_filter mit rerun_group=cross-os, wenn eine Cross-OS-Lane fehlgeschlagen ist. Der Filter akzeptiert eine OS-ID, eine Suite-ID oder ein OS-/Suite-Paar, zum Beispiel windows/packaged-upgrade, windows oder packaged-fresh. Cross-OS- Zusammenfassungen enthalten timings pro Phase für Packaged-Upgrade-Lanes, und lang laufende Befehle geben Heartbeat-Zeilen aus, damit ein hängendes Windows-Update vor dem Job-Timeout sichtbar ist.

Fehlschläge bei QA-Release-Checks blockieren die normale Release-Validierung. Erforderlicher OpenClaw- Dynamic-Tool-Drift im Standard-Tier blockiert ebenfalls den Release-Check-Verifier. Tideclaw-Alpha-Läufe können Nicht-Package-Safety-Release-Check-Lanes weiterhin als advisory behandeln. Wenn live_suite_filter ausdrücklich eine gated QA-Live-Lane wie Discord, WhatsApp oder Slack anfordert, muss die passende OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED-Repo-Variable 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 frische QA-Nachweise benötigen.

Aufzubewahrende Nachweise

Behalten Sie die Zusammenfassung Full Release Validation als Release-weiten Index bei. Sie verlinkt Child-Run-IDs und enthält Tabellen der langsamsten Jobs. Prüfen Sie bei Fehlschlägen zuerst den Child- Workflow und führen Sie dann den kleinsten passenden Handle oben erneut aus.

Nützliche Artefakte:

• release-package-under-test aus OpenClaw Release Checks
• Docker-Release-Pfad-Artefakte unter .artifacts/docker-tests/
• Package Acceptance package-under-test und Docker-Acceptance-Artefakte
• Cross-OS-Release-Check-Artefakte für jedes OS und jede Suite
• QA-Paritäts-, Matrix- und Telegram-Artefakte

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/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml