Pełna walidacja wydania

Full Release Validation to nadrzędny proces wydania: pojedynczy ręczny punkt wejścia do weryfikacji przed wydaniem. Większość zadań jest wykonywana w podrzędnych przepływach pracy, dzięki czemu zadanie zakończone niepowodzeniem można uruchomić ponownie bez ponownego rozpoczynania całego wydania.

Uruchom go z zaufanego odwołania przepływu pracy, zwykle main, i przekaż gałąź wydania, tag lub 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=stable

provider akceptuje również anthropic lub minimax na potrzeby wdrażania w różnych systemach operacyjnych oraz pełnego przebiegu agenta. Zadania podrzędne wielokrotnego użytku ustalają środowisko wywoływanego przepływu pracy na podstawie job.workflow_repository i job.workflow_sha, natomiast parametr wejściowy ref wybiera testowanego kandydata. Dzięki temu bieżąca zaufana logika walidacji pozostaje dostępna podczas walidowania starszej gałęzi lub starszego tagu wydania.

Każdy uruchomiony proces podrzędny musi zgłosić ten sam SHA przepływu pracy co nadrzędne uruchomienie Full Release Validation. Jeśli main zmieni się między uruchomieniem procesu nadrzędnego a procesów podrzędnych, proces nadrzędny zakończy się bezpiecznym niepowodzeniem, nawet jeśli sam proces podrzędny się powiedzie. Aby uzyskać niezmienny dowód dla dokładnego commita, użyj pnpm ci:full-release --sha <target-sha>. Narzędzie pomocnicze tworzy tymczasowe odwołanie release-ci/* przypięte do bieżącego zaufanego origin/main, przekazuje docelowy SHA wyłącznie jako ref kandydata, ponownie wykorzystuje ścisłe dowody dla dokładnego celu, gdy są dostępne, i usuwa odwołanie po walidacji. Przekaż -f reuse_evidence=false, aby wymusić nowe uruchomienie, lub --workflow-sha <trusted-main-sha>, aby wybrać starszy commit przepływu pracy, który nadal jest osiągalny z bieżącego origin/main. Sam przepływ pracy nigdy nie tworzy ani nie aktualizuje odwołań repozytorium.

release_profile=stable i release_profile=full zawsze uruchamiają wyczerpujący długotrwały test środowiska rzeczywistego/Dockera. Przekaż run_release_soak=true, aby uwzględnić te same ścieżki długotrwałych testów w profilu beta. Publikacja stabilna odrzuca manifest walidacji bez tego długotrwałego testu oraz blokujących dowodów wydajności produktu.

Package Acceptance zwykle buduje archiwum tar kandydata z rozpoznanego ref, w tym dla uruchomień z pełnym SHA wywołanych za pomocą pnpm ci:full-release. Po opublikowaniu wersji beta przekaż release_package_spec=openclaw@YYYY.M.PATCH-beta.N, aby ponownie wykorzystać wydany pakiet npm w kontrolach wydania, Package Acceptance, testach międzyplatformowych, ścieżce wydania Dockera i testach pakietu Telegram. Używaj package_acceptance_package_spec tylko wtedy, gdy Package Acceptance ma celowo zweryfikować inny pakiet. Ścieżka testów rzeczywistych pakietu Pluginu Codex działa według tego samego stanu: opublikowane wartości release_package_spec wyznaczają codex_plugin_spec=npm:@openclaw/codex@<version>; uruchomienia SHA/artefaktów pakują extensions/codex z wybranego odwołania, a operatorzy mogą ustawić codex_plugin_spec bezpośrednio dla źródeł Pluginu npm:, npm-pack: lub git:. Ścieżka udziela jawnej zgody na instalację CLI Codex wymaganej przez ten Plugin, a następnie wykonuje kontrolę wstępną CLI Codex i przebiegi agenta OpenAI w tej samej sesji.

Etapy najwyższego poziomu

Dla rerun_group=all najpierw wykonywane jest zadanie Check for reusable validation evidence: wyszukuje ono najnowszą wcześniejszą zakończoną powodzeniem pełną walidację dla dokładnie tego samego docelowego SHA, profilu wydania, efektywnego ustawienia długotrwałego testu i parametrów wejściowych walidacji. Gdy taki dowód istnieje, każda ścieżka jest pomijana, a nadrzędny weryfikator ponownie sprawdza niezmienny artefakt nadrzędny, uruchomienia podrzędne i dzienniki wywołań. Jest to wyłącznie mechanizm odzyskiwania po ponownym uruchomieniu tego samego kandydata; nie zezwala na ponowne użycie między różnymi SHA. W przypadku zmienionego kandydata uruchom ponownie każdą kontrolę pakietu, artefaktu, instalacji, Dockera lub dostawcy, na którą wpływa ta zmiana. Przekaż reuse_evidence=false, aby wymusić nową pełną walidację. Ponowne użycie dowodów działa tylko z main lub kanonicznego, przypiętego do SHA odwołania release-ci/*, którego commit przepływu pracy pozostaje w zaufanej linii main; inne odwołania przepływu pracy uruchamiają wybrane ścieżki od nowa.

Również dla rerun_group=all zadanie Verify Docker runtime image assets buduje cel Dockera runtime-assets z OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Działa ono równolegle z innymi etapami i jest egzekwowane przez nadrzędny weryfikator; ścieżki nie czekają już na jego zakończenie przed uruchomieniem. Węższa wartość rerun_group pomija tę kontrolę wstępną.

Proces nadrzędny zawsze uruchamia testy wydajności produktu w trybie wyłącznie artefaktowym. OpenClaw Performance zezwala na publikację raportu tylko dla zaplanowanych uruchomień lub ręcznego wywołania, które jawnie ustawia publish_reports=true. Kontrola trybu wyłącznie artefaktowego musi zakończyć się powodzeniem, potwierdzając, że zadanie publikujące pozostało pominięte. Nowe i ponownie użyte dowody zapisują controls.performanceReportPublication=artifact-only; weryfikator i selektor ponownego użycia odrzucają dowody bez pasującego, znormalizowanego potwierdzenia z podrzędnego procesu wydajnościowego.

Weryfikator przesyła kanoniczny manifest jako full-release-validation-<run-id>-<run-attempt>. Narzędzia obsługi dowodów weryfikują identyfikator artefaktu, skrót, uruchomienie producenta i próbę przed pobraniem tego dokładnego identyfikatora artefaktu. Nakładają limit na pobierany plik ZIP, weryfikują jego bajty względem skrótu REST sha256: i strumieniowo odczytują jedyny dozwolony wpis manifestu o ograniczonym rozmiarze bez rozpakowywania archiwum. Alias o stabilnej nazwie pozostaje tymczasowo dla starszych konsumentów publikacji. Weryfikator zawsze preferuje artefakt z nazwą uwzględniającą próbę; przejściowo akceptuje stabilną nazwę tylko dla producenta manifestu v2 z pierwszej próby. Odrzuca tę starszą nazwę dla późniejszych prób i manifestu v3.

Dla ref=main z rerun_group=all, dla odwołań release/* oraz odwołań alfa Tideclaw nowsze uruchomienie procesu nadrzędnego zastępuje starsze o tym samym odwołaniu i tej samej grupie ponownego uruchomienia. Gdy proces nadrzędny zostaje anulowany, jego monitor anuluje każdy podrzędny przepływ pracy, który został już uruchomiony. Uruchomienia walidacji tagów i przypiętych SHA nie anulują się wzajemnie.

Etapy kontroli wydania

OpenClaw Release Checks jest największym podrzędnym przepływem pracy. Jednorazowo rozpoznaje cel i przygotowuje współdzielony artefakt release-package-under-test, gdy wymagają go etapy związane z pakietem lub Dockerem.

Fragmenty dockerowej ścieżki wydania

Etap dockerowej ścieżki wydania uruchamia następujące fragmenty, gdy live_suite_filter jest pusty:

Gdy nie powiedzie się tylko jedna ścieżka Dockera, użyj ukierunkowanego docker_lanes=<lane[,lane]> w przepływie pracy wielokrotnego użytku dla testów na żywo/E2E. Artefakty wydania zawierają polecenia ponownego uruchomienia dla poszczególnych ścieżek wraz z parametrami ponownego użycia artefaktu pakietu i obrazu, jeśli są dostępne.

Profile wydania

release_profile steruje głównie zakresem testów live/dostawców w ramach kontroli wydania. Nie usuwa standardowego pełnego CI, wersji przedpremierowej Pluginu, testu dymnego instalacji, akceptacji pakietu ani QA Lab. Profile stabilny i pełny zawsze uruchamiają wyczerpujące testy E2E repozytorium/live oraz długotrwałe testy ścieżki wydania w Dockerze. Profil beta może je włączyć za pomocą run_release_soak=true. Akceptacja pakietu zapewnia kanoniczny test E2E Telegramu dla pakietu w przypadku każdego pełnego kandydata, dlatego nadrzędny przepływ nie powiela tego pollera live.

Dodatki tylko dla profilu pełnego

Poniższe zestawy są pomijane przez stable i uwzględniane przez full:

stable obejmuje native-live-src-gateway-profiles-anthropic-smoke oraz native-live-src-gateway-profiles-opencode-go-smoke; full używa zamiast nich szerszych fragmentów modeli Anthropic i OpenCode Go. Ukierunkowane ponowne uruchomienia mogą nadal używać zbiorczych uchwytów native-live-src-gateway-profiles-anthropic lub native-live-src-gateway-profiles-opencode-go.

Ukierunkowane ponowne uruchomienia

Użyj rerun_group, aby uniknąć powtarzania niepowiązanych środowisk wydania:

Gdy nie powiedzie się jeden zestaw live, użyj live_suite_filter z rerun_group=live-e2e. Prawidłowe identyfikatory filtrów są zdefiniowane w przepływie wielokrotnego użytku live/E2E i obejmują 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 trzech fragmentów dostawców, dlatego nadal rozdziela się na wszystkie doradcze zadania Gateway w Dockerze.

Gdy nie powiedzie się jedna ścieżka obejmująca wiele systemów operacyjnych, użyj cross_os_suite_filter z rerun_group=cross-os. Filtr przyjmuje identyfikator systemu operacyjnego, identyfikator zestawu lub parę system/zestaw, na przykład windows/packaged-upgrade, windows albo packaged-fresh. Podsumowania dla wielu systemów operacyjnych obejmują czasy poszczególnych faz ścieżek aktualizacji pakietowej, a długotrwałe polecenia wypisują wiersze Heartbeat, dzięki czemu zawieszoną aktualizację można zauważyć przed przekroczeniem limitu czasu zadania.

Niepowodzenia kontroli wydania QA blokują standardową walidację wydania. Kontrola pokrycia narzędzi środowiska uruchomieniowego QA (dynamiczne rozbieżności narzędzi między openclaw a codex na poziomie standardowym) również blokuje weryfikator kontroli wydania, mimo że bazowa ścieżka zgodności środowiska uruchomieniowego QA ma charakter doradczy. Uruchomienia alfa Tideclaw mogą nadal traktować ścieżki kontroli wydania niezwiązane z bezpieczeństwem pakietu jako doradcze. Przy release_profile=beta zestawy dostawców live w ramach Run repo/live E2E validation mają charakter doradczy: wdrożenia modeli innych firm zmieniają się niezależnie od wydania, dlatego profil beta przedstawia ich niepowodzenia jako ostrzeżenia, podczas gdy profile stabilny i pełny nadal traktują je jako blokujące. Gdy live_suite_filter jawnie żąda warunkowej ścieżki QA live, takiej jak Discord, WhatsApp lub Slack, odpowiednia zmienna repozytorium OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED musi być włączona; w przeciwnym razie przechwytywanie danych wejściowych kończy się niepowodzeniem zamiast po cichu pomijać ścieżkę. Uruchom ponownie rerun_group=qa, qa-parity lub qa-live, gdy potrzebujesz aktualnych danych potwierdzających QA.

Dane, które należy zachować

Zachowaj podsumowanie Full Release Validation jako indeks na poziomie wydania. Zawiera ono odnośniki do identyfikatorów przebiegów podrzędnych oraz tabele najwolniejszych zadań. W przypadku niepowodzeń najpierw sprawdź przepływ podrzędny, a następnie ponownie uruchom najmniejszy pasujący uchwyt wymieniony powyżej.

Przydatne artefakty:

• release-package-under-test z OpenClaw Release Checks
• artefakty ścieżki wydania w Dockerze w .artifacts/docker-tests/
• artefakty package-under-test z akceptacji pakietu oraz artefakty akceptacji w Dockerze
• artefakty kontroli wydania na różnych systemach operacyjnych dla każdego systemu i zestawu
• artefakty zgodności QA, zgodności środowiska uruchomieniowego, Matrix i Telegramu

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/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