Release and CI
Pełna walidacja wydania
Full Release Validation jest nadrzędnym parasolem wydania. To pojedynczy ręczny
punkt wejścia dla dowodu przed wydaniem, ale większość pracy odbywa się w podrzędnych przepływach pracy, aby
nieudany element można było uruchomić ponownie bez restartowania całego wydania.
Uruchom go z zaufanego odniesienia przepływu pracy, 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.D \ -f provider=openai \ -f mode=both \ -f release_profile=stablePodrzędne przepływy pracy używają zaufanego odniesienia przepływu pracy dla harnessu oraz wejścia
ref dla kandydata objętego testem. Dzięki temu nowa logika walidacji pozostaje dostępna
podczas walidowania starszej gałęzi wydania lub taga.
Domyślnie release_profile=stable uruchamia ścieżki blokujące wydanie i pomija
wyczerpujący live/Docker soak. Przekaż run_release_soak=true, aby uwzględnić
ścieżki soak w stabilnym uruchomieniu. release_profile=full zawsze włącza ścieżki soak, aby
szeroki profil doradczy nigdy po cichu nie tracił pokrycia.
Package Acceptance zwykle buduje tarball kandydata z rozwiązanego
ref, w tym uruchomienia z pełnym SHA wywołane przez pnpm ci:full-release. Po
opublikowaniu wersji beta przekaż release_package_spec=openclaw@YYYY.M.D-beta.N, aby ponownie użyć
wysłanego pakietu npm w kontrolach wydania, Package Acceptance, cross-OS,
release-path Docker i package Telegram. Używaj package_acceptance_package_spec
tylko wtedy, gdy Package Acceptance ma celowo udowodnić inny pakiet.
Etapy najwyższego poziomu
| Etap | Szczegóły |
|---|---|
| Rozwiązanie celu | Zadanie: Resolve target ref |
| Podrzędny przepływ pracy: brak | |
| Dowodzi: rozwiązuje gałąź wydania, tag lub pełny SHA commita i zapisuje wybrane wejścia. | |
| Ponowne uruchomienie: uruchom ponownie parasol, jeśli to się nie powiedzie. | |
| Vitest i normalne CI | Zadanie: Run normal full CI |
Podrzędny przepływ pracy: CI |
|
Dowodzi: ręczny pełny graf CI względem docelowego odniesienia, w tym ścieżki Linux Node, shardy dołączonych pluginów, kontrakty kanałów, zgodność z Node 22, check, check-additional, build smoke, kontrole dokumentacji, Skills Pythona, Windows, macOS, i18n Control UI oraz Android przez parasol. |
|
Ponowne uruchomienie: rerun_group=ci. |
|
| Przedwydanie pluginów | Zadanie: Run plugin prerelease validation |
Podrzędny przepływ pracy: Plugin Prerelease |
|
Dowodzi: tylko wydaniowe statyczne kontrole pluginów, agentowe pokrycie pluginów, pełne shardy wsadowe rozszerzeń, przedwydaniowe ścieżki Docker pluginów oraz nieblokujący artefakt plugin-inspector-advisory do triage'u zgodności. |
|
Ponowne uruchomienie: rerun_group=plugin-prerelease. |
|
| Kontrole wydania | Zadanie: Run release/live/Docker/QA validation |
Podrzędny przepływ pracy: OpenClaw Release Checks |
|
Dowodzi: install smoke, kontrole pakietów cross-OS, Package Acceptance, parytet QA Lab, live Matrix i live Telegram. Z run_release_soak=true lub release_profile=full uruchamia także wyczerpujące zestawy live/E2E oraz fragmenty release-path Docker. |
|
Ponowne uruchomienie: rerun_group=release-checks lub węższy uchwyt release-checks. |
|
| Artefakt pakietu | Zadanie: Prepare release package artifact |
| Podrzędny przepływ pracy: brak | |
Dowodzi: tworzy nadrzędny tarball release-package-under-test wystarczająco wcześnie dla kontroli skierowanych na pakiet, które nie muszą czekać na OpenClaw Release Checks. |
|
Ponowne uruchomienie: uruchom ponownie parasol albo podaj release_package_spec dla ponownych uruchomień opublikowanego pakietu. |
|
| Package Telegram | Zadanie: Run package Telegram E2E |
Podrzędny przepływ pracy: NPM Telegram Beta E2E |
|
Dowodzi: dowód pakietu Telegram oparty na artefakcie nadrzędnym dla rerun_group=all z release_profile=full albo dowód Telegram dla opublikowanego pakietu, gdy ustawiono release_package_spec lub npm_telegram_package_spec. |
|
Ponowne uruchomienie: rerun_group=npm-telegram z release_package_spec lub npm_telegram_package_spec. |
|
| Weryfikator parasola | Zadanie: Verify full validation |
| Podrzędny przepływ pracy: brak | |
| Dowodzi: ponownie sprawdza zapisane konkluzje uruchomień podrzędnych i dołącza tabele najwolniejszych zadań z podrzędnych przepływów pracy. | |
| Ponowne uruchomienie: uruchom ponownie tylko to zadanie po doprowadzeniu nieudanego przepływu podrzędnego do stanu zielonego. |
Dla ref=main i rerun_group=all nowszy parasol zastępuje starszy.
Gdy element nadrzędny zostanie anulowany, jego monitor anuluje każdy podrzędny przepływ pracy, który już
wysłał. Uruchomienia walidacji gałęzi wydania i tagów domyślnie nie anulują się nawzajem.
Etapy kontroli wydania
OpenClaw Release Checks to największy podrzędny przepływ pracy. Rozwiązuje cel
raz i przygotowuje współdzielony artefakt release-package-under-test, gdy potrzebują go etapy
skierowane na pakiet lub Docker.
| Etap | Szczegóły |
|---|---|
| Cel wydania | Zadanie: Resolve target ref |
| Przepływ pracy bazowy: brak | |
| Testy: wybrany ref, opcjonalny oczekiwany SHA, profil, grupa ponownego uruchomienia i ukierunkowany filtr pakietu testów live. | |
Ponowne uruchomienie: rerun_group=release-checks. |
|
| Artefakt pakietu | Zadanie: Prepare release package artifact |
| Przepływ pracy bazowy: brak | |
Testy: pakuje albo rozwiązuje jeden kandydacki tarball i przesyła release-package-under-test do dalszych kontroli dotyczących pakietu. |
|
| Ponowne uruchomienie: dotknięty pakiet, grupa cross-OS albo live/E2E. | |
| Smoke instalacji | Zadanie: Run install smoke |
Przepływ pracy bazowy: Install Smoke |
|
| Testy: pełna ścieżka instalacji z ponownym użyciem obrazu smoke z głównego Dockerfile, instalacja pakietu QR, smoke głównego i Gateway w Dockerze, testy instalatora w Dockerze, smoke dostawcy obrazów dla globalnej instalacji Bun oraz szybkie E2E instalacji/deinstalacji dołączonych pluginów. | |
Ponowne uruchomienie: rerun_group=install-smoke. |
|
| Cross-OS | Zadanie: cross_os_release_checks |
Przepływ pracy bazowy: OpenClaw Cross-OS Release Checks (Reusable) |
|
| Testy: ścieżki świeżej instalacji i aktualizacji w systemach Linux, Windows i macOS dla wybranego dostawcy i trybu, z użyciem kandydackiego tarballa oraz pakietu bazowego. | |
Ponowne uruchomienie: rerun_group=cross-os. |
|
| Repozytorium i live E2E | Zadanie: Run repo/live E2E validation |
Przepływ pracy bazowy: OpenClaw Live And E2E Checks (Reusable) |
|
Testy: E2E repozytorium, cache live, strumieniowanie OpenAI websocket, natywne shardy dostawcy live i pluginów oraz oparte na Dockerze harnessy live model/backend/gateway wybrane przez release_profile. |
|
Uruchomienia: run_release_soak=true, release_profile=full albo ukierunkowane 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 |
Przepływ pracy 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 ukierunkowane rerun_group=live-e2e. |
|
Ponowne uruchomienie: rerun_group=live-e2e. |
|
| Akceptacja pakietu | Zadanie: Run package acceptance |
Przepływ pracy bazowy: Package Acceptance |
|
Testy: offline fixture’y pakietów pluginów, aktualizacja pluginu, akceptacja pakietu Telegram z mock-OpenAI oraz kontrole przetrwania po aktualizacji z opublikowanej wersji względem tego samego tarballa. Blokujące kontrole wydania używają domyślnej najnowszej opublikowanej bazy; kontrole soak rozszerzają zakres do każdego stabilnego wydania npm od 2026.4.23 włącznie oraz fixture’ów zgłoszonych problemów. |
|
Ponowne uruchomienie: rerun_group=package. |
|
| Parzystość QA | Zadanie: Run QA Lab parity lane i Run QA Lab parity report |
| Przepływ pracy bazowy: zadania bezpośrednie | |
| Testy: kandydackie i bazowe pakiety parzystości agentowej, a następnie raport parzystości. | |
Ponowne uruchomienie: rerun_group=qa-parity albo rerun_group=qa. |
|
| QA live Matrix | Zadanie: Run QA Lab live Matrix lane |
| Przepływ pracy 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. |
|
| QA live Telegram | Zadanie: Run QA Lab live Telegram lane |
| Przepływ pracy 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 |
| Przepływ pracy bazowy: brak | |
| Testy: wymagane zadania kontroli wydania dla wybranej grupy ponownego uruchomienia. | |
| Ponowne uruchomienie: uruchom ponownie po przejściu ukierunkowanych zadań podrzędnych. |
Fragmenty ścieżki wydania Docker
Etap ścieżki wydania Docker uruchamia te fragmenty, gdy live_suite_filter jest
pusty:
| Fragment | Pokrycie |
|---|---|
core |
Główne ścieżki smoke ścieżki wydania Docker. |
package-update-openai |
Zachowanie instalacji/aktualizacji pakietu OpenAI, instalacja Codex na żądanie i wywołania narzędzi Chat Completions. |
package-update-anthropic |
Zachowanie instalacji i aktualizacji pakietu Anthropic. |
package-update-core |
Neutralne względem dostawcy zachowanie pakietu i aktualizacji. |
plugins-runtime-plugins |
Ścieżki środowiska uruchomieniowego pluginów, które wykonują zachowanie pluginów. |
plugins-runtime-services |
Ścieżki środowiska uruchomieniowego pluginów opartych na usługach i live; obejmuje OpenWebUI, gdy jest wymagane. |
plugins-runtime-install-a through plugins-runtime-install-h |
Partie instalacji/środowiska uruchomieniowego pluginów podzielone na potrzeby równoległej walidacji wydania. |
Użyj ukierunkowanego docker_lanes=<lane[,lane]> w przepływie pracy live/E2E wielokrotnego użytku, gdy
zawiodła tylko jedna ścieżka Docker. Artefakty wydania obejmują polecenia
ponownego uruchomienia dla poszczególnych ścieżek z wejściami artefaktu pakietu
i ponownego użycia obrazu, gdy są dostępne.
Profile wydania
release_profile kontroluje głównie zakres live/dostawców w kontrolach wydania.
Nie usuwa normalnego pełnego CI, Plugin Prerelease, smoke instalacji, akceptacji
pakietu ani QA Lab. Dla stable wyczerpujące repo/live E2E i fragmenty ścieżki
wydania Docker są pokryciem soak i uruchamiają się, gdy run_release_soak=true.
full wymusza włączenie pokrycia soak, a także sprawia, że nadrzędne uruchomienie
wykonuje E2E pakietu Telegram względem nadrzędnego artefaktu pakietu wydania,
gdy rerun_group=all, więc pełny kandydat przed publikacją nie pomija po cichu
tej ścieżki pakietu Telegram.
| Profil | Zamierzone użycie | Uwzględnione pokrycie live/dostawców |
|---|---|---|
minimum |
Najszybszy smoke krytyczny dla wydania. | Ścieżka live OpenAI/core, modele live Docker dla OpenAI, natywny rdzeń Gateway, natywny profil Gateway OpenAI, natywny plugin OpenAI i live Gateway OpenAI w Dockerze. |
stable |
Domyślny profil zatwierdzania wydania. | minimum plus smoke Anthropic, Google, MiniMax, backend, natywny harness testów live, backend CLI live w Dockerze, bind ACP w Dockerze, harness Codex w Dockerze i shard smoke OpenCode Go. |
full |
Szeroki przegląd doradczy. | stable plus dostawcy doradczy, shardy live pluginów i shardy live mediów. |
Dodatki tylko dla full
Te pakiety testów są pomijane przez stable i uwzględniane przez full:
| Obszar | Pokrycie tylko dla full |
|---|---|
| Modele live Docker | OpenCode Go, OpenRouter, xAI, Z.ai i Fireworks. |
| Gateway live Docker | 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ów | Pluginy A-K, L-N, O-Z inne, 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. Ukierunkowane ponowne
uruchomienia nadal mogą używać zagregowanych uchwytów
native-live-src-gateway-profiles-anthropic albo
native-live-src-gateway-profiles-opencode-go.
Ukierunkowane ponowne uruchomienia
Użyj rerun_group, aby uniknąć powtarzania niepowiązanych pól wydania:
| Uchwyt | Zakres |
|---|---|
all |
Wszystkie etapy pełnej walidacji wydania. |
ci |
Tylko ręczny podrzędny pełny CI. |
plugin-prerelease |
Tylko podrzędne wstępne wydanie Plugin. |
release-checks |
Wszystkie etapy kontroli wydania OpenClaw. |
install-smoke |
Smoke instalacji przez kontrole wydania. |
cross-os |
Kontrole wydania między systemami operacyjnymi. |
live-e2e |
Walidacja repo/live E2E i ścieżki wydania Docker. |
package |
Akceptacja pakietu. |
qa |
Parzystość QA oraz aktywne ścieżki QA. |
qa-parity |
Tylko ścieżki parzystości QA i raport. |
qa-live |
Tylko aktywne Matrix i Telegram w QA. |
npm-telegram |
Telegram E2E dla opublikowanego pakietu; wymaga release_package_spec lub npm_telegram_package_spec. |
Użyj live_suite_filter z rerun_group=live-e2e, gdy nie powiedzie się jeden aktywny zestaw.
Prawidłowe identyfikatory filtrów są zdefiniowane w wielokrotnie używanym przepływie pracy 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 zagregowanym uchwytem ponownego uruchomienia dla swoich
trzech fragmentów dostawców, więc nadal rozdziela się na wszystkie zadania doradcze Docker Gateway.
Użyj cross_os_suite_filter z rerun_group=cross-os, gdy nie powiedzie się jedna ścieżka między systemami operacyjnymi.
Filtr akceptuje identyfikator systemu operacyjnego, identyfikator zestawu albo parę system/zestaw, na
przykład windows/packaged-upgrade, windows lub packaged-fresh. Podsumowania między systemami operacyjnymi
zawierają czasy poszczególnych faz dla ścieżek uaktualnienia pakietowego, a długo działające
polecenia wypisują wiersze Heartbeat, aby zablokowana aktualizacja Windows była widoczna przed
limitem czasu zadania.
Ścieżki QA kontroli wydania są doradcze. Awaria dotycząca tylko QA jest zgłaszana jako ostrzeżenie
i nie blokuje weryfikatora kontroli wydania; uruchom ponownie rerun_group=qa,
qa-parity albo 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 przebiegów podrzędnych i zawiera tabele najwolniejszych zadań. W przypadku awarii najpierw sprawdź podrzędny
przepływ pracy, a następnie uruchom ponownie najmniejszy pasujący uchwyt z powyższych.
Przydatne artefakty:
release-package-under-testz nadrzędnego przepływu pełnej walidacji wydania orazOpenClaw Release Checks- Artefakty ścieżki wydania Docker w
.artifacts/docker-tests/ - Artefakty akceptacji pakietu
package-under-testi akceptacji Docker - Artefakty kontroli wydania między systemami operacyjnymi dla każdego systemu operacyjnego i zestawu
- Artefakty parzystości QA, Matrix i Telegram
Pliki przepływów pracy
.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