Release and CI
Pełna walidacja wydania
Full Release Validation to nadrzędna walidacja wydania. Jest pojedynczym ręcznym
punktem wejścia dla dowodów przedwydaniowych, ale większość pracy odbywa się w podrzędnych workflow, aby
nieudane środowisko można było uruchomić ponownie bez restartowania całego wydania.
Uruchom ją z zaufanej referencji workflow, zwykle main, i przekaż gałąź wydania,
tag albo pełny SHA commita jako 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=stablePodrzędne workflow używają zaufanej referencji workflow dla harnessa oraz wejściowego
ref dla kandydata objętego testami. Dzięki temu nowa logika walidacji jest dostępna
podczas walidowania starszej gałęzi wydania albo tagu.
release_profile=stable i release_profile=full zawsze uruchamiają wyczerpujący
soak live/Docker. Przekaż run_release_soak=true, aby włączyć te same ścieżki soak
z profilem beta. Publikacja stable odrzuca manifest walidacji bez tych
dowodów soak i blokujących dowodów wydajności produktu.
Akceptacja pakietu zwykle buduje tarball kandydata z rozwiązanej
referencji ref, w tym uruchomienia z pełnym SHA wywołane przez pnpm ci:full-release. Po
publikacji beta przekaż release_package_spec=openclaw@YYYY.M.PATCH-beta.N, aby ponownie użyć
opublikowanego pakietu npm w kontrolach wydania, akceptacji pakietu, testach cross-OS,
Docker dla ścieżki wydania oraz pakietowym Telegram. Używaj package_acceptance_package_spec
tylko wtedy, gdy akceptacja pakietu ma celowo udowodnić inny pakiet.
Ścieżka pakietu live Pluginu Codex zachowuje ten sam stan: opublikowane
wartości release_package_spec wyprowadzają codex_plugin_spec=npm:@openclaw/codex@<version>;
uruchomienia SHA/artefaktów pakują extensions/codex z wybranej referencji; a operatorzy
mogą ustawić codex_plugin_spec bezpośrednio dla źródeł Pluginu npm:, npm-pack: lub git:.
Ta ścieżka przyznaje jawne zatwierdzenie instalacji Codex CLI wymagane przez
ten Plugin, a następnie uruchamia preflight Codex CLI i tury agenta OpenAI w tej samej sesji.
Etapy najwyższego poziomu
| Etap | Szczegóły |
|---|---|
| Rozwiązanie celu | Zadanie: Resolve target ref |
| Podrzędne workflow: brak | |
| Udowadnia: rozwiązuje gałąź wydania, tag albo pełny SHA commita i zapisuje wybrane dane wejściowe. | |
| Ponowne uruchomienie: uruchom ponownie nadrzędną walidację, jeśli to się nie powiedzie. | |
| Vitest i zwykłe CI | Zadanie: Run normal full CI |
Podrzędne workflow: CI |
|
Udowadnia: ręczny pełny graf CI względem docelowej referencji, w tym ścieżki Linux Node, shardy dołączonych Pluginów, shardy kontraktów Pluginów i kanałów, zgodność z Node 22, check-*, check-additional-*, kontrole smoke zbudowanych artefaktów, kontrole dokumentacji, Skills Python, Windows, macOS, i18n Control UI oraz Android przez nadrzędną walidację. |
|
Ponowne uruchomienie: rerun_group=ci. |
|
| Przedwydaniowa walidacja Pluginów | Zadanie: Run plugin prerelease validation |
Podrzędne workflow: Plugin Prerelease |
|
Udowadnia: statyczne kontrole Pluginów tylko dla wydania, agentową pokrywalność Pluginów, pełne shardy partii rozszerzeń, przedwydaniowe ścieżki Docker dla Pluginów oraz nieblokujący artefakt plugin-inspector-advisory do triage zgodności. |
|
Ponowne uruchomienie: rerun_group=plugin-prerelease. |
|
| Kontrole wydania | Zadanie: Run release/live/Docker/QA validation |
Podrzędne workflow: OpenClaw Release Checks |
|
Udowadnia: smoke instalacji, kontrole pakietu cross-OS, akceptację pakietu, parytet QA Lab, Matrix live oraz Telegram live. Profile stable i full uruchamiają też wyczerpujące pakiety live/E2E oraz fragmenty Docker dla ścieżki wydania; beta może je włączyć przez run_release_soak=true. |
|
Ponowne uruchomienie: rerun_group=release-checks albo węższy uchwyt release-checks. |
|
| Pakietowy Telegram | Zadanie: Run package Telegram E2E |
Podrzędne workflow: NPM Telegram Beta E2E |
|
Udowadnia: ukierunkowane E2E Telegram dla opublikowanego pakietu, gdy ustawiono release_package_spec albo npm_telegram_package_spec. Pełna walidacja kandydata używa zamiast tego kanonicznego E2E Telegram z akceptacji pakietu. |
|
Ponowne uruchomienie: rerun_group=npm-telegram z release_package_spec albo npm_telegram_package_spec. |
|
| Weryfikator nadrzędny | Zadanie: Verify full validation |
| Podrzędne workflow: brak | |
| Udowadnia: ponownie sprawdza zapisane konkluzje uruchomień podrzędnych i dołącza tabele najwolniejszych zadań z podrzędnych workflow. | |
| Ponowne uruchomienie: uruchom ponownie tylko to zadanie po ponownym uruchomieniu nieudanego procesu podrzędnego do stanu zielonego. |
Dla ref=main i rerun_group=all nowsza nadrzędna walidacja zastępuje starszą.
Gdy rodzic zostaje anulowany, jego monitor anuluje każde podrzędne workflow, które już
uruchomił. Uruchomienia walidacji gałęzi wydania i tagów domyślnie nie anulują się
wzajemnie.
Etapy kontroli wydania
OpenClaw Release Checks to największe podrzędne workflow. Rozwiązuje cel
raz i przygotowuje współdzielony artefakt release-package-under-test, gdy potrzebują go etapy
dotyczące pakietu albo Docker.
| Etap | Szczegóły |
|---|---|
| Cel wydania | Zadanie: Resolve target ref |
| Workflow bazowy: brak | |
| Testy: wybrany ref, opcjonalny oczekiwany SHA, profil, grupa ponownego uruchomienia i zawężony filtr zestawu live. | |
Ponowne uruchomienie: rerun_group=release-checks. |
|
| Artefakt pakietu | Zadanie: Prepare release package artifact |
| Workflow bazowy: brak | |
Testy: pakuje albo wybiera jeden kandydacki tarball i przesyła release-package-under-test dla dalszych kontroli dotyczących pakietu. |
|
| Ponowne uruchomienie: odpowiedni pakiet, grupa cross-OS albo live/E2E. | |
| Smoke instalacji | Zadanie: Run install smoke |
Workflow bazowy: Install Smoke |
|
| Testy: pełna ścieżka instalacji z ponownym użyciem obrazu smoke z głównego Dockerfile, instalacja pakietu QR, smoke Dockera dla roota i Gateway, testy Dockera instalatora, smoke globalnej instalacji Bun dla image-provider oraz szybkie E2E instalacji/deinstalacji wbudowanego Plugin. | |
Ponowne uruchomienie: rerun_group=install-smoke. |
|
| Cross-OS | Zadanie: cross_os_release_checks |
Workflow bazowy: OpenClaw Cross-OS Release Checks (Reusable) |
|
| Testy: ścieżki świeżej instalacji i aktualizacji na Linuxie, Windowsie i macOS dla wybranego dostawcy i trybu, z użyciem kandydackiego tarballa oraz pakietu bazowego. | |
Ponowne uruchomienie: rerun_group=cross-os. |
|
| Repo i live E2E | Zadanie: Run repo/live E2E validation |
Workflow bazowy: OpenClaw Live And E2E Checks (Reusable) |
|
Testy: E2E repozytorium, cache live, streaming WebSocket OpenAI, natywne shardy live dostawców i Plugin oraz harnessy live modelu/backendu/Gateway oparte na Dockerze, wybierane przez release_profile. |
|
Uruchomienia: run_release_soak=true, release_profile=full albo zawężone rerun_group=live-e2e. |
|
Ponowne uruchomienie: rerun_group=live-e2e, opcjonalnie z live_suite_filter. |
|
| Ścieżka wydania Docker | Zadanie: Run Docker release-path validation |
Workflow bazowy: OpenClaw Live And E2E Checks (Reusable) |
|
| Testy: fragmenty ścieżki wydania Docker względem współdzielonego artefaktu pakietu. | |
Uruchomienia: run_release_soak=true, release_profile=full albo zawężone rerun_group=live-e2e. |
|
Ponowne uruchomienie: rerun_group=live-e2e. |
|
| Akceptacja pakietu | Zadanie: Run package acceptance |
Workflow bazowy: Package Acceptance |
|
Testy: offline’owe fixture’y pakietów Plugin, aktualizacja Plugin, kanoniczne E2E pakietu mock-OpenAI Telegram oraz kontrole przetrwania aktualizacji z opublikowanej wersji względem tego samego tarballa. Blokujące kontrole wydania używają domyślnej najnowszej opublikowanej bazy; kontrole soak rozszerzają zakres na każde stabilne wydanie npm od 2026.4.23 włącznie oraz fixture’y zgłoszonych problemów. |
|
Ponowne uruchomienie: rerun_group=package. |
|
| Parzystość QA | Zadanie: Run QA Lab parity lane i Run QA Lab parity report |
| Workflow bazowy: zadania bezpośrednie | |
| Testy: pakiety parzystości agentowej kandydata i bazy, a następnie raport parzystości. | |
Ponowne uruchomienie: rerun_group=qa-parity albo rerun_group=qa. |
|
| Macierz QA live | Zadanie: Run QA Lab live Matrix lane |
| Workflow bazowy: zadanie bezpośrednie | |
Testy: szybki profil QA live Matrix w środowisku qa-live-shared. |
|
Ponowne uruchomienie: rerun_group=qa-live albo rerun_group=qa. |
|
| Telegram QA live | Zadanie: Run QA Lab live Telegram lane |
| Workflow bazowy: zadanie bezpośrednie | |
| Testy: QA live Telegram z dzierżawami poświadczeń Convex CI. | |
Ponowne uruchomienie: rerun_group=qa-live albo rerun_group=qa. |
|
| Weryfikator wydania | Zadanie: Verify release checks |
| Workflow bazowy: brak | |
| Testy: wymagane zadania kontroli wydania dla wybranej grupy ponownego uruchomienia. | |
| Ponowne uruchomienie: uruchom ponownie po przejściu zawężonych zadań podrzędnych. |
Fragmenty ścieżki wydania Docker
Etap ścieżki wydania Docker uruchamia te fragmenty, gdy live_suite_filter jest
pusty:
| Fragment | Zakres |
|---|---|
core |
Ścieżki smoke głównej ścieżki wydania Docker. |
package-update-openai |
Zachowanie instalacji/aktualizacji pakietu OpenAI, instalacja Codex na żądanie, tury live Plugin Codex i wywołania narzędzi Chat Completions. |
package-update-anthropic |
Zachowanie instalacji i aktualizacji pakietu Anthropic. |
package-update-core |
Zachowanie pakietu i aktualizacji neutralne względem dostawcy. |
plugins-runtime-plugins |
Ścieżki środowiska uruchomieniowego Plugin, które sprawdzają zachowanie Plugin. |
plugins-runtime-services |
Ścieżki środowiska uruchomieniowego Plugin oparte na usługach i live; obejmuje OpenWebUI, gdy jest wymagane. |
plugins-runtime-install-a do plugins-runtime-install-h |
Partie instalacji/środowiska uruchomieniowego Plugin podzielone na potrzeby równoległej walidacji wydania. |
Użyj ukierunkowanego docker_lanes=<lane[,lane]> w wielokrotnego użytku workflow live/E2E, gdy
nie powiodła się tylko jedna ścieżka Docker. Artefakty wydania zawierają polecenia ponownego uruchomienia
dla poszczególnych ścieżek z artefaktem pakietu i wejściami ponownego użycia obrazu, gdy są dostępne.
Profile wydania
release_profile kontroluje głównie szerokość live/dostawców w kontrolach wydania.
Nie usuwa normalnego pełnego CI, Plugin Prerelease, smoke instalacji, akceptacji pakietu
ani QA Lab. Profile stabilny i pełny zawsze uruchamiają wyczerpujące E2E repo/live
oraz pokrycie soak ścieżki wydania Docker. Profil beta może włączyć je przez
run_release_soak=true. Package Acceptance dostarcza kanoniczne E2E pakietu
Telegram dla każdego pełnego kandydata, więc workflow zbiorczy nie duplikuje tego
pollera live.
| Profil | Zamierzone użycie | Uwzględnione pokrycie live/dostawców |
|---|---|---|
minimum |
Najszybszy smoke krytyczny dla wydania. | Ścieżka live OpenAI/core, modele Docker live dla OpenAI, natywny rdzeń Gateway, natywny profil Gateway OpenAI, natywny Plugin OpenAI i Docker live Gateway OpenAI. |
stable |
Domyślny profil zatwierdzania wydania. | minimum plus smoke Anthropic, Google, MiniMax, backend, natywny harness testów live, backend CLI Docker live, bind Docker ACP, harness Docker Codex i shard smoke OpenCode Go. |
full |
Szeroki przegląd doradczy. | stable plus dostawcy doradczy, shardy live Plugin i shardy live mediów. |
Dodatki tylko w pełnym profilu
Te zestawy są pomijane przez stable i uwzględniane przez full:
| Obszar | Pokrycie tylko w pełnym profilu |
|---|---|
| Modele Docker live | OpenCode Go, OpenRouter, xAI, Z.ai i Fireworks. |
| Gateway Docker live | Dostawcy doradczy podzieleni na shardy DeepSeek/Fireworks, OpenCode Go/OpenRouter oraz xAI/Z.ai. |
| Natywne profile dostawców Gateway | Pełne shardy Anthropic Opus i Sonnet/Haiku, Fireworks, DeepSeek, pełne shardy modeli OpenCode Go, OpenRouter, xAI i Z.ai. |
| Natywne shardy live Plugin | Plugins A-K, L-N, O-Z other, Moonshot i xAI. |
| Natywne shardy live mediów | Audio, muzyka Google, muzyka MiniMax i grupy wideo A-D. |
stable obejmuje native-live-src-gateway-profiles-anthropic-smoke i
native-live-src-gateway-profiles-opencode-go-smoke; full używa zamiast tego szerszych
shardów modeli Anthropic i OpenCode Go. Zawężone ponowne uruchomienia nadal mogą używać
zbiorczych uchwytów native-live-src-gateway-profiles-anthropic albo
native-live-src-gateway-profiles-opencode-go.
Zawężone ponowne uruchomienia
Użyj rerun_group, aby uniknąć powtarzania niezwiązanych pól wydania:
| Uchwyt | Zakres |
|---|---|
all |
Wszystkie etapy pełnej walidacji wydania. |
ci |
Tylko podrzędny ręczny pełny CI. |
plugin-prerelease |
Tylko podrzędny etap przedpremierowy Plugin. |
release-checks |
Wszystkie etapy kontroli wydania OpenClaw. |
install-smoke |
Install Smoke przez kontrole wydania. |
cross-os |
Kontrole wydania dla wielu systemów operacyjnych. |
live-e2e |
Walidacja E2E repo/live i ścieżki wydania Docker. |
package |
Akceptacja pakietu. |
qa |
Parzystość QA oraz ścieżki QA live. |
qa-parity |
Tylko ścieżki parzystości QA i raport. |
qa-live |
Matrix/Telegram QA live oraz bramkowane ścieżki Discord, WhatsApp i Slack, gdy są włączone. |
npm-telegram |
Telegram E2E opublikowanego pakietu; wymaga release_package_spec lub npm_telegram_package_spec. |
Użyj live_suite_filter z rerun_group=live-e2e, gdy jeden pakiet live zakończył się niepowodzeniem.
Prawidłowe identyfikatory filtrów są zdefiniowane w wielokrotnego użytku workflow live/E2E, w tym
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 oraz
live-codex-harness-docker.
Uchwyt live-gateway-advisory-docker jest zbiorczym uchwytem ponownego uruchomienia dla jego
trzech shardów dostawców, więc nadal rozgałęzia się na wszystkie zadania advisory Docker gateway.
Użyj cross_os_suite_filter z rerun_group=cross-os, gdy jedna ścieżka dla wielu systemów operacyjnych
zakończyła się niepowodzeniem. Filtr akceptuje identyfikator systemu operacyjnego, identyfikator pakietu albo parę system/pakiet, na
przykład windows/packaged-upgrade, windows lub packaged-fresh. Podsumowania dla wielu systemów operacyjnych
zawierają czasy poszczególnych faz dla ścieżek aktualizacji pakietowej, a długotrwałe
polecenia wypisują linie heartbeat, dzięki czemu zablokowana aktualizacja Windows jest widoczna przed
limitem czasu zadania.
Niepowodzenia kontroli wydania QA blokują normalną walidację wydania. Wymagany dryf dynamicznych narzędzi OpenClaw
w standardowej warstwie również blokuje weryfikator kontroli wydania.
Uruchomienia Tideclaw alpha mogą nadal traktować ścieżki kontroli wydania niezwiązane z bezpieczeństwem pakietu jako
doradcze. Gdy live_suite_filter jawnie żąda bramkowanej ścieżki QA live, takiej
jak Discord, WhatsApp lub Slack, odpowiadająca zmienna repozytorium
OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED musi być włączona; w przeciwnym razie
przechwytywanie wejścia kończy się niepowodzeniem zamiast po cichu pominąć ścieżkę. Uruchom ponownie rerun_group=qa,
qa-parity lub qa-live, gdy potrzebujesz świeżych dowodów QA.
Dowody do zachowania
Zachowaj podsumowanie Full Release Validation jako indeks na poziomie wydania. Łączy ono
identyfikatory uruchomień podrzędnych i zawiera tabele najwolniejszych zadań. W przypadku niepowodzeń najpierw sprawdź podrzędny
workflow, a następnie uruchom ponownie najmniejszy pasujący uchwyt powyżej.
Przydatne artefakty:
release-package-under-testzOpenClaw Release Checks- Artefakty ścieżki wydania Docker w
.artifacts/docker-tests/ package-under-testz akceptacji pakietu oraz artefakty akceptacji Docker- Artefakty kontroli wydania dla wielu systemów operacyjnych dla każdego systemu operacyjnego i pakietu
- Artefakty parzystości QA, Matrix i Telegram
Pliki workflow
.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
