chore(i18n): refresh pl translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
4f32a540a7
commit
669b008e04
320
docs/pl/ci.md
320
docs/pl/ci.md
@ -1,75 +1,75 @@
|
||||
---
|
||||
read_when:
|
||||
- Musisz zrozumieć, dlaczego zadanie CI zostało lub nie zostało uruchomione
|
||||
- Debugujesz nieudane sprawdzenie GitHub Actions
|
||||
- Debugujesz nieudaną kontrolę GitHub Actions
|
||||
- Koordynujesz uruchomienie lub ponowne uruchomienie walidacji wydania
|
||||
summary: Graf zadań CI, bramki zakresu, parasole wydań i lokalne odpowiedniki poleceń
|
||||
title: Potok CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T09:41:27Z"
|
||||
generated_at: "2026-04-30T18:39:07Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62
|
||||
source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd
|
||||
source_path: ci.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw CI uruchamia się przy każdym wypchnięciu do `main` i dla każdego pull requestu. Zadanie `preflight` klasyfikuje diff i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo omijają inteligentne zawężanie zakresu i rozwijają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Androida pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Plugin Prerelease`](#plugin-prerelease) i uruchamia się tylko z [`Full Release Validation`](#full-release-validation) albo przez jawne ręczne wywołanie.
|
||||
OpenClaw CI uruchamia się przy każdym wypchnięciu do `main` i dla każdego pull requesta. Zadanie `preflight` klasyfikuje różnicę i wyłącza kosztowne ścieżki, gdy zmieniły się tylko niepowiązane obszary. Ręczne uruchomienia `workflow_dispatch` celowo omijają inteligentne zawężanie zakresu i rozgałęziają pełny graf dla kandydatów do wydania oraz szerokiej walidacji. Ścieżki Android pozostają opcjonalne przez `include_android`. Pokrycie Plugin tylko dla wydań znajduje się w osobnym workflow [`Wstępne wydanie Plugin`](#plugin-prerelease) i uruchamia się tylko z [`Pełnej walidacji wydania`](#full-release-validation) albo przez jawne ręczne wywołanie.
|
||||
|
||||
## Przegląd potoku
|
||||
|
||||
| Zadanie | Cel | Kiedy się uruchamia |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- |
|
||||
| `preflight` | Wykrywa zmiany wyłącznie w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze dla niedraftowych wypchnięć i PR-ów |
|
||||
| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze dla niedraftowych wypchnięć i PR-ów |
|
||||
| `security-dependency-audit` | Audyt produkcyjnego lockfile bez instalowania zależności względem advisory npm | Zawsze dla niedraftowych wypchnięć i PR-ów |
|
||||
| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze dla niedraftowych wypchnięć i PR-ów |
|
||||
| `check-dependencies` | Produkcyjny przebieg Knip tylko dla zależności oraz strażnik listy dozwolonych nieużywanych plików | Zmiany istotne dla Node |
|
||||
| `build-artifacts` | Buduje `dist/`, Control UI, kontrole zbudowanych artefaktów i artefakty wielokrotnego użytku dla dalszych zadań | Zmiany istotne dla Node |
|
||||
| `checks-fast-core` | Szybkie linuksowe ścieżki poprawności, takie jak kontrole dołączonych Pluginów, kontraktów Pluginów i protokołu | Zmiany istotne dla Node |
|
||||
| `checks-fast-contracts-channels` | Shardowane kontrole kontraktów kanałów ze stabilnym zagregowanym wynikiem kontroli | Zmiany istotne dla Node |
|
||||
| `checks-node-core-test` | Shardy testów rdzenia Node, z wyłączeniem ścieżek kanałów, dołączonych elementów, kontraktów i rozszerzeń | Zmiany istotne dla Node |
|
||||
| `check` | Shardowany odpowiednik głównej lokalnej bramki: typy produkcyjne, lint, strażniki, typy testów i rygorystyczny smoke test | Zmiany istotne dla Node |
|
||||
| `check-additional` | Shardy architektury, granic, strażników powierzchni rozszerzeń, granic pakietów i gateway-watch | Zmiany istotne dla Node |
|
||||
| `build-smoke` | Smoke testy zbudowanego CLI i smoke test pamięci przy uruchomieniu | Zmiany istotne dla Node |
|
||||
| `checks` | Weryfikator testów kanałów dla zbudowanych artefaktów | Zmiany istotne dla Node |
|
||||
| `checks-node-compat-node22` | Ścieżka budowania zgodności z Node 22 i smoke testu | Ręczne wywołanie CI dla wydań |
|
||||
| `check-docs` | Formatowanie dokumentacji, lint i kontrole uszkodzonych linków | Zmieniona dokumentacja |
|
||||
| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla pythonowych Skills |
|
||||
| `checks-windows` | Testy procesów/ścieżek specyficzne dla Windows oraz regresje współdzielonych specyfikatorów importu runtime | Zmiany istotne dla Windows |
|
||||
| `macos-node` | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS |
|
||||
| `macos-swift` | Swift lint, budowanie i testy aplikacji macOS | Zmiany istotne dla macOS |
|
||||
| `android` | Testy jednostkowe Androida dla obu wariantów oraz jedno zbudowanie debug APK | Zmiany istotne dla Androida |
|
||||
| `test-performance-agent` | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności | Powodzenie CI na main albo ręczne wywołanie |
|
||||
| `preflight` | Wykrywa zmiany tylko w dokumentacji, zmienione zakresy, zmienione rozszerzenia i buduje manifest CI | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami |
|
||||
| `security-scm-fast` | Wykrywanie kluczy prywatnych i audyt workflow przez `zizmor` | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami |
|
||||
| `security-dependency-audit` | Audyt produkcyjnego lockfile bez zależności względem ostrzeżeń npm | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami |
|
||||
| `security-fast` | Wymagany agregat dla szybkich zadań bezpieczeństwa | Zawsze przy wypchnięciach i PR-ach, które nie są szkicami |
|
||||
| `check-dependencies` | Produkcyjne przejście Knip tylko dla zależności oraz strażnik listy dozwolonych nieużywanych plików | Zmiany istotne dla Node |
|
||||
| `build-artifacts` | Buduje `dist/`, Control UI, sprawdzenia zbudowanych artefaktów i artefakty wielokrotnego użytku dla zadań podrzędnych | Zmiany istotne dla Node |
|
||||
| `checks-fast-core` | Szybkie linuksowe ścieżki poprawności, takie jak sprawdzenia bundled/plugin-contract/protocol | Zmiany istotne dla Node |
|
||||
| `checks-fast-contracts-channels` | Shardowane sprawdzenia kontraktów kanałów ze stabilnym zagregowanym wynikiem sprawdzenia | Zmiany istotne dla Node |
|
||||
| `checks-node-core-test` | Shardy testów rdzenia Node, z wyłączeniem ścieżek kanałów, bundled, kontraktów i rozszerzeń | Zmiany istotne dla Node |
|
||||
| `check` | Shardowany odpowiednik głównej lokalnej bramki: typy produkcyjne, lint, strażniki, typy testów i rygorystyczny smoke | Zmiany istotne dla Node |
|
||||
| `check-additional` | Shardy architektury, granic, strażników powierzchni rozszerzeń, granic pakietów i gateway-watch | Zmiany istotne dla Node |
|
||||
| `build-smoke` | Testy smoke zbudowanego CLI i smoke pamięci startowej | Zmiany istotne dla Node |
|
||||
| `checks` | Weryfikator testów kanałów dla zbudowanych artefaktów | Zmiany istotne dla Node |
|
||||
| `checks-node-compat-node22` | Ścieżka budowania i smoke zgodności z Node 22 | Ręczne wywołanie CI dla wydań |
|
||||
| `check-docs` | Formatowanie dokumentacji, lint i sprawdzenia niedziałających linków | Zmieniono dokumentację |
|
||||
| `skills-python` | Ruff + pytest dla Skills opartych na Pythonie | Zmiany istotne dla Python-skill |
|
||||
| `checks-windows` | Testy procesów/ścieżek specyficzne dla Windows oraz współdzielone regresje specyfikatorów importu runtime | Zmiany istotne dla Windows |
|
||||
| `macos-node` | Ścieżka testów TypeScript na macOS używająca współdzielonych zbudowanych artefaktów | Zmiany istotne dla macOS |
|
||||
| `macos-swift` | Swift lint, budowanie i testy aplikacji macOS | Zmiany istotne dla macOS |
|
||||
| `android` | Testy jednostkowe Android dla obu wariantów oraz jedna kompilacja debug APK | Zmiany istotne dla Android |
|
||||
| `test-performance-agent` | Codzienna optymalizacja wolnych testów przez Codex po zaufanej aktywności | Sukces CI na main albo ręczne wywołanie |
|
||||
|
||||
## Kolejność fail-fast
|
||||
## Kolejność szybkiego niepowodzenia
|
||||
|
||||
1. `preflight` decyduje, które ścieżki w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie osobne zadania.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` kończą się niepowodzeniem szybko, bez czekania na cięższe zadania artefaktów i macierzy platform.
|
||||
3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby dalsi konsumenci mogli wystartować, gdy tylko wspólna kompilacja będzie gotowa.
|
||||
4. Cięższe ścieżki platform i runtime rozwijają się potem: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
|
||||
1. `preflight` decyduje, które ścieżki w ogóle istnieją. Logika `docs-scope` i `changed-scope` to kroki wewnątrz tego zadania, a nie samodzielne zadania.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` i `skills-python` szybko kończą się niepowodzeniem bez czekania na cięższe zadania artefaktów i macierzy platform.
|
||||
3. `build-artifacts` nakłada się z szybkimi ścieżkami Linuksa, aby konsumenci podrzędni mogli wystartować, gdy tylko współdzielone budowanie będzie gotowe.
|
||||
4. Cięższe ścieżki platform i runtime rozgałęziają się później: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` i `android`.
|
||||
|
||||
GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo refa `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tego samego refa również kończy się niepowodzeniem. Zagregowane kontrole shardów używają `!cancelled() && always()`, więc nadal raportują zwykłe niepowodzenia shardów, ale nie kolejkują się po tym, jak całe workflow zostało już zastąpione. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHuba w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują trwających uruchomień.
|
||||
GitHub może oznaczać zastąpione zadania jako `cancelled`, gdy nowsze wypchnięcie trafi do tego samego PR-a albo referencji `main`. Traktuj to jako szum CI, chyba że najnowsze uruchomienie dla tej samej referencji również kończy się niepowodzeniem. Zagregowane sprawdzenia shardów używają `!cancelled() && always()`, więc nadal zgłaszają normalne niepowodzenia shardów, ale nie kolejkowują się po tym, jak cały workflow został już zastąpiony. Automatyczny klucz współbieżności CI jest wersjonowany (`CI-v7-*`), aby zombie po stronie GitHub w starej grupie kolejki nie mogło bezterminowo blokować nowszych uruchomień main. Ręczne uruchomienia pełnego zestawu używają `CI-manual-v1-*` i nie anulują uruchomień w toku.
|
||||
|
||||
## Zakres i routowanie
|
||||
|
||||
Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest pokryta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne wywołanie pomija wykrywanie changed-scope i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy obszar objęty zakresem.
|
||||
Logika zakresu znajduje się w `scripts/ci-changed-scope.mjs` i jest objęta testami jednostkowymi w `src/scripts/ci-changed-scope.test.ts`. Ręczne wywołanie pomija wykrywanie changed-scope i sprawia, że manifest preflight zachowuje się tak, jakby zmienił się każdy zakresowy obszar.
|
||||
|
||||
- **Edycje workflow CI** walidują graf CI Node oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Androida ani macOS; te ścieżki platform pozostają ograniczone do zmian źródeł platformowych.
|
||||
- **Edycje wyłącznie routingu CI, wybrane tanie edycje fixture’ów testów rdzenia oraz wąskie edycje pomocnicze/routingu testów kontraktów Pluginów** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i jedno zadanie `checks-fast-core`. Ta ścieżka pomija artefakty budowania, zgodność z Node 22, kontrakty kanałów, pełne shardy rdzenia, shardy dołączonych Pluginów i dodatkowe macierze strażników, gdy zmiana ogranicza się do powierzchni routingu lub pomocniczych, które szybkie zadanie ćwiczy bezpośrednio.
|
||||
- **Kontrole Node dla Windows** są ograniczone do specyficznych dla Windows wrapperów procesów/ścieżek, helperów runnerów npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które wykonują tę ścieżkę; niepowiązane zmiany źródeł, Pluginów, install-smoke i wyłącznie testowe pozostają na linuksowych ścieżkach Node.
|
||||
- **Edycje workflow CI** walidują graf CI Node oraz linting workflow, ale same nie wymuszają natywnych buildów Windows, Android ani macOS; te ścieżki platform pozostają zawężone do zmian w źródłach platform.
|
||||
- **Edycje dotyczące tylko routowania CI, wybrane tanie edycje fixture testów rdzenia oraz wąskie edycje pomocnicze/routingu testów kontraktu Plugin** używają szybkiej ścieżki manifestu tylko dla Node: `preflight`, bezpieczeństwo i jedno zadanie `checks-fast-core`. Ta ścieżka pomija artefakty budowania, zgodność z Node 22, kontrakty kanałów, pełne shardy rdzenia, shardy bundled-plugin oraz dodatkowe macierze strażników, gdy zmiana jest ograniczona do powierzchni routingu lub pomocniczych, które szybkie zadanie ćwiczy bezpośrednio.
|
||||
- **Sprawdzenia Node na Windows** są zawężone do specyficznych dla Windows wrapperów procesów/ścieżek, pomocników runnerów npm/pnpm/UI, konfiguracji menedżera pakietów oraz powierzchni workflow CI, które wykonują tę ścieżkę; niepowiązane zmiany źródeł, Plugin, install-smoke i tylko testów pozostają na linuksowych ścieżkach Node.
|
||||
|
||||
Najwolniejsze rodziny testów Node są dzielone lub równoważone, aby każde zadanie pozostawało małe bez nadmiernej rezerwacji runnerów: kontrakty kanałów działają jako trzy ważone shardy, małe ścieżki jednostkowe rdzenia są parowane, auto-reply działa jako czterech zrównoważonych workerów (z poddrzewem odpowiedzi podzielonym na shardy agent-runner, dispatch oraz commands/state-routing), a agentic konfiguracje Gateway/Plugin są rozłożone między istniejące zadania agentic Node tylko dla źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarki, QA, mediów i różne testy Pluginów używają własnych dedykowanych konfiguracji Vitest zamiast wspólnego catch-all dla Pluginów. Shardy include-pattern zapisują wpisy czasów z użyciem nazwy sharda CI, więc `.artifacts/vitest-shard-timings.json` może odróżnić całą konfigurację od filtrowanego sharda. `check-additional` trzyma razem prace kompilacji/canary granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; shard strażnika granic uruchamia swoje małe niezależne strażniki współbieżnie w jednym zadaniu. Gateway watch, testy kanałów i shard granicy wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane.
|
||||
Najwolniejsze rodziny testów Node są dzielone lub balansowane tak, aby każde zadanie pozostało małe bez nadmiernego rezerwowania runnerów: kontrakty kanałów uruchamiają się jako trzy ważone shardy, małe ścieżki jednostkowe rdzenia są parowane, auto-reply działa jako czterech zbalansowanych workerów (z poddrzewem reply podzielonym na shardy agent-runner, dispatch oraz commands/state-routing), a agentowe konfiguracje Gateway/Plugin są rozłożone na istniejące agentowe zadania Node tylko ze źródeł zamiast czekać na zbudowane artefakty. Szerokie testy przeglądarkowe, QA, multimediów i różne testy Plugin używają dedykowanych konfiguracji Vitest zamiast współdzielonego catch-all dla Plugin. Shardy include-pattern zapisują wpisy czasów z użyciem nazwy sharda CI, więc `.artifacts/vitest-shard-timings.json` może odróżnić całą konfigurację od przefiltrowanego sharda. `check-additional` trzyma razem pracę kompilacji/canary dla granic pakietów i oddziela architekturę topologii runtime od pokrycia gateway watch; shard strażnika granic uruchamia swoje małe niezależne strażniki współbieżnie w jednym zadaniu. Gateway watch, testy kanałów i shard granic wsparcia rdzenia działają współbieżnie wewnątrz `build-artifacts` po tym, jak `dist/` i `dist-runtime/` są już zbudowane.
|
||||
|
||||
CI Androida uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig SMS/call-log, unikając jednocześnie duplikowania zadania pakowania debug APK przy każdym wypchnięciu istotnym dla Androida.
|
||||
Android CI uruchamia zarówno `testPlayDebugUnitTest`, jak i `testThirdPartyDebugUnitTest`, a następnie buduje Play debug APK. Wariant third-party nie ma osobnego zestawu źródeł ani manifestu; jego ścieżka testów jednostkowych nadal kompiluje wariant z flagami BuildConfig SMS/call-log, unikając jednocześnie zduplikowanego zadania pakowania debug APK przy każdym wypchnięciu istotnym dla Android.
|
||||
|
||||
Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjny przebieg Knip tylko dla zależności przypięty do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, które porównuje produkcyjne znaleziska nieużywanych plików Knip z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików kończy się niepowodzeniem, gdy PR dodaje nowy nieprzejrzany nieużywany plik albo zostawia przestarzały wpis na liście dozwolonych, zachowując przy tym celowe dynamiczne powierzchnie Pluginów, wygenerowane, build, live-test i mosty pakietów, których Knip nie może rozwiązać statycznie.
|
||||
Shard `check-dependencies` uruchamia `pnpm deadcode:dependencies` (produkcyjne przejście Knip tylko dla zależności przypięte do najnowszej wersji Knip, z wyłączonym minimalnym wiekiem wydania pnpm dla instalacji `dlx`) oraz `pnpm deadcode:unused-files`, które porównuje produkcyjne znaleziska nieużywanych plików z Knip z `scripts/deadcode-unused-files.allowlist.mjs`. Strażnik nieużywanych plików kończy się niepowodzeniem, gdy PR dodaje nowy, niezweryfikowany nieużywany plik albo pozostawia nieaktualny wpis listy dozwolonych, zachowując jednocześnie intencjonalne dynamiczne powierzchnie Plugin, generowane, build, live-test i mosty pakietów, których Knip nie może rozwiązać statycznie.
|
||||
|
||||
## Ręczne wywołania
|
||||
|
||||
Ręczne wywołania CI uruchamiają ten sam graf zadań co normalne CI, ale wymuszają każdą nieandroidową ścieżkę objętą zakresem: shardy Linux Node, shardy dołączonych Pluginów, kontrakty kanałów, zgodność z Node 22, `check`, `check-additional`, build smoke, kontrole dokumentacji, pythonowe Skills, Windows, macOS i i18n Control UI. Samodzielne ręczne wywołania CI uruchamiają Androida tylko z `include_android=true`; parasol pełnego wydania włącza Androida przez przekazanie `include_android=true`. Statyczne kontrole prerelease Pluginów, wyłącznie wydaniowy shard `agentic-plugins`, pełny wsadowy przegląd rozszerzeń i dockerowe ścieżki prerelease Pluginów są wyłączone z CI. Zestaw Docker prerelease uruchamia się tylko wtedy, gdy `Full Release Validation` wywołuje osobny workflow `Plugin Prerelease` z włączoną bramką release-validation.
|
||||
Ręczne wywołania CI uruchamiają ten sam graf zadań co normalne CI, ale wymuszają każdą zakresową ścieżkę poza Android: shardy Linux Node, shardy bundled-plugin, kontrakty kanałów, zgodność Node 22, `check`, `check-additional`, build smoke, sprawdzenia dokumentacji, Python skills, Windows, macOS i i18n Control UI. Samodzielne ręczne wywołania CI uruchamiają Android tylko z `include_android=true`; parasol pełnego wydania włącza Android, przekazując `include_android=true`. Statyczne sprawdzenia wstępnego wydania Plugin, shard tylko dla wydania `agentic-plugins`, pełny sweep batch rozszerzeń oraz ścieżki Docker wstępnego wydania Plugin są wykluczone z CI. Pakiet Docker wstępnego wydania uruchamia się tylko wtedy, gdy `Full Release Validation` wywołuje osobny workflow `Plugin Prerelease` z włączoną bramką release-validation.
|
||||
|
||||
Ręczne uruchomienia używają unikalnej grupy współbieżności, więc pełny zestaw dla kandydata do wydania nie jest anulowany przez inne wypchnięcie albo uruchomienie PR na tym samym refie. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem brancha, taga albo pełnego SHA commita, używając pliku workflow z wybranego refa wywołania.
|
||||
Ręczne uruchomienia używają unikalnej grupy współbieżności, więc pełny zestaw dla kandydata do wydania nie jest anulowany przez inne wypchnięcie ani uruchomienie PR na tej samej referencji. Opcjonalne wejście `target_ref` pozwala zaufanemu wywołującemu uruchomić ten graf względem brancha, tagu albo pełnego SHA commita, używając pliku workflow z wybranej referencji wywołania.
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref release/YYYY.M.D
|
||||
@ -77,17 +77,17 @@ gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_andro
|
||||
gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
|
||||
```
|
||||
|
||||
## Runnery
|
||||
## Runery
|
||||
|
||||
| Uruchamiacz | Zadania |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, szybkie zadania bezpieczeństwa i agregaty (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktu/pakietów, shardowane kontrole kontraktów kanałów, shardy `check` z wyjątkiem lint, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła wcześniej trafić do kolejki |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` i `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shardy testów Node w Linuksie, shardy testów pakietowych pluginów, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (na tyle wrażliwe na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); buildy Docker install-smoke (czas oczekiwania w kolejce dla 32 vCPU kosztował więcej, niż oszczędzał) |
|
||||
| Runner | Zadania |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, szybkie zadania i agregaty bezpieczeństwa (`security-scm-fast`, `security-dependency-audit`, `security-fast`), szybkie kontrole protokołu/kontraktu/wbudowanych elementów, shardowane kontrole kontraktu kanałów, shardy `check` z wyjątkiem lintingu, shardy i agregaty `check-additional`, weryfikatory agregatów testów Node, kontrole dokumentacji, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke także używa Ubuntu hostowanego przez GitHub, aby macierz Blacksmith mogła kolejkować się wcześniej |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lżejsze shardy rozszerzeń, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` oraz `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shardy testów Node dla Linuksa, shardy testów wbudowanych pluginów, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (wystarczająco wrażliwy na CPU, że 8 vCPU kosztowało więcej, niż oszczędzało); kompilacje Docker install-smoke (czas kolejki 32 vCPU kosztował więcej, niż oszczędzał) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` w `openclaw/openclaw`; forki wracają do `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki wracają do `macos-latest` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` w `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` w `openclaw/openclaw`; forki przechodzą awaryjnie na `macos-latest` |
|
||||
|
||||
## Lokalne odpowiedniki
|
||||
|
||||
@ -117,27 +117,27 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
|
||||
## Pełna walidacja wydania
|
||||
|
||||
`Full Release Validation` to ręczny nadrzędny workflow do „uruchomienia wszystkiego przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodu dotyczącego wyłącznie wydania: pluginów/pakietów/statyki/Dockera, oraz uruchamia `OpenClaw Release Checks` dla install smoke, package acceptance, zestawów ścieżki wydania Dockera, live/E2E, OpenWebUI, parytetu QA Lab, Matrix i ścieżek Telegram. Może też uruchomić powydaniowy workflow `NPM Telegram Beta E2E`, gdy podano specyfikację opublikowanego pakietu.
|
||||
`Full Release Validation` to ręczny nadrzędny workflow dla „uruchom wszystko przed wydaniem”. Przyjmuje gałąź, tag lub pełny SHA commita, uruchamia ręczny workflow `CI` z tym celem, uruchamia `Plugin Prerelease` dla dowodu dotyczącego wyłącznie wydania: pluginu/pakietu/statycznych zasobów/Docker, oraz uruchamia `OpenClaw Release Checks` dla smoke testów instalacji, akceptacji pakietu, zestawów ścieżki wydania Docker, live/E2E, OpenWebUI, zgodności QA Lab, Matrix i ścieżek Telegram. Może także uruchomić powydaniowy workflow `NPM Telegram Beta E2E`, gdy podano specyfikację opublikowanego pakietu.
|
||||
|
||||
`release_profile` kontroluje zakres live/provider przekazywany do kontroli wydania:
|
||||
`release_profile` steruje zakresem live/provider przekazywanym do kontroli wydania:
|
||||
|
||||
- `minimum` zachowuje najszybsze krytyczne dla wydania ścieżki OpenAI/core.
|
||||
- `minimum` zachowuje najszybsze krytyczne dla wydania ścieżki OpenAI/rdzenia.
|
||||
- `stable` dodaje stabilny zestaw provider/backend.
|
||||
- `full` uruchamia szeroką macierz doradczą provider/media.
|
||||
|
||||
Nadrzędny workflow zapisuje identyfikatory uruchomionych workflow potomnych, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące wyniki workflow potomnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia potomnego. Jeśli workflow potomny zostanie ponownie uruchomiony i zakończy się powodzeniem, uruchom ponownie tylko zadanie weryfikatora nadrzędnego, aby odświeżyć wynik nadrzędny i podsumowanie czasu.
|
||||
Workflow nadrzędny zapisuje identyfikatory uruchomionych workflow podrzędnych, a końcowe zadanie `Verify full validation` ponownie sprawdza bieżące konkluzje uruchomień podrzędnych i dołącza tabele najwolniejszych zadań dla każdego uruchomienia podrzędnego. Jeśli workflow podrzędny zostanie uruchomiony ponownie i zakończy się powodzeniem, uruchom ponownie tylko zadanie weryfikujące rodzica, aby odświeżyć wynik workflow nadrzędnego i podsumowanie czasów.
|
||||
|
||||
Do odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` akceptują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla normalnego pełnego workflow potomnego CI, `release-checks` dla każdego potomnego zadania wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w workflow nadrzędnym. Dzięki temu ponowne uruchomienie nieudanego środowiska wydania pozostaje ograniczone po ukierunkowanej poprawce.
|
||||
Do odzyskiwania zarówno `Full Release Validation`, jak i `OpenClaw Release Checks` przyjmują `rerun_group`. Użyj `all` dla kandydata do wydania, `ci` tylko dla zwykłego pełnego podrzędnego CI, `release-checks` dla każdego podrzędnego zadania wydania albo węższej grupy: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` lub `npm-telegram` w workflow nadrzędnym. Dzięki temu ponowne uruchomienie nieudanego zestawu wydania pozostaje ograniczone po ukierunkowanej poprawce.
|
||||
|
||||
`OpenClaw Release Checks` używa zaufanego ref workflow, aby jednorazowo rozwiązać wybrany ref do tarballa `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Dockera dla ścieżki wydania live/E2E, jak i do sharda package acceptance. Dzięki temu bajty pakietu pozostają spójne między środowiskami wydania i unika się ponownego pakowania tego samego kandydata w wielu zadaniach potomnych.
|
||||
`OpenClaw Release Checks` używa zaufanego odniesienia workflow, aby jednorazowo rozwiązać wybrane odniesienie do tarballa `release-package-under-test`, a następnie przekazuje ten artefakt zarówno do workflow Docker ścieżki wydania live/E2E, jak i do sharda akceptacji pakietu. To utrzymuje spójne bajty pakietu między zestawami wydania i unika ponownego pakowania tego samego kandydata w wielu zadaniach podrzędnych.
|
||||
|
||||
## Shardy live i E2E
|
||||
|
||||
Potomny workflow live/E2E wydania zachowuje szeroki natywny zakres `pnpm test:live`, ale uruchamia go jako nazwane shardy przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego:
|
||||
Podrzędny workflow wydania live/E2E zachowuje szerokie natywne pokrycie `pnpm test:live`, ale uruchamia je jako nazwane shardy przez `scripts/test-live-shard.mjs` zamiast jednego zadania szeregowego:
|
||||
|
||||
- `native-live-src-agents`
|
||||
- `native-live-src-gateway-core`
|
||||
- zadania `native-live-src-gateway-profiles` filtrowane według providera
|
||||
- filtrowane według providera zadania `native-live-src-gateway-profiles`
|
||||
- `native-live-src-gateway-backends`
|
||||
- `native-live-test`
|
||||
- `native-live-extensions-a-k`
|
||||
@ -145,57 +145,57 @@ Potomny workflow live/E2E wydania zachowuje szeroki natywny zakres `pnpm test:li
|
||||
- `native-live-extensions-openai`
|
||||
- `native-live-extensions-o-z-other`
|
||||
- `native-live-extensions-xai`
|
||||
- rozdzielone shardy mediów audio/wideo oraz shardy muzyki filtrowane według providera
|
||||
- podzielone shardy audio/wideo mediów oraz filtrowane według providera shardy muzyki
|
||||
|
||||
Zachowuje to ten sam zakres plików, a jednocześnie ułatwia ponowne uruchamianie i diagnozowanie wolnych awarii providerów live. Zbiorcze nazwy shardów `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień.
|
||||
Dzięki temu zachowane jest to samo pokrycie plików, a powolne awarie providerów live są łatwiejsze do ponownego uruchomienia i diagnozowania. Nazwy agregatów shardów `native-live-extensions-o-z`, `native-live-extensions-media` i `native-live-extensions-media-music` pozostają prawidłowe dla ręcznych jednorazowych ponownych uruchomień.
|
||||
|
||||
Natywne shardy mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, zbudowanym przez workflow `Live Media Runner Image`. Ten obraz wstępnie instaluje `ffmpeg` i `ffprobe`; zadania mediów przed konfiguracją tylko weryfikują binaria. Zachowaj pakiety testów live oparte na Dockerze na normalnych runnerach Blacksmith — zadania kontenerowe nie są właściwym miejscem do uruchamiania zagnieżdżonych testów Dockera.
|
||||
Natywne shardy mediów live działają w `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, zbudowanym przez workflow `Live Media Runner Image`. Ten obraz wstępnie instaluje `ffmpeg` i `ffprobe`; zadania mediów tylko weryfikują pliki binarne przed konfiguracją. Utrzymuj zestawy live oparte na Docker na zwykłych runnerach Blacksmith — zadania kontenerowe są niewłaściwym miejscem do uruchamiania zagnieżdżonych testów Docker.
|
||||
|
||||
Shardy modeli/backendów live oparte na Dockerze używają osobnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:<sha>` dla wybranego commita. Workflow wydania live buduje i wypycha ten obraz raz, a następnie shardy modelu live Dockera, Gateway, backendu CLI, wiązania ACP i harnessa Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Jeśli te shardy niezależnie przebudowują pełny docelowy obraz Dockera ze źródeł, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas zegarowy na zduplikowane buildy obrazu.
|
||||
Shardy modeli/backendów live oparte na Docker używają oddzielnego współdzielonego obrazu `ghcr.io/openclaw/openclaw-live-test:<sha>` dla wybranego commita. Workflow wydania live buduje i wypycha ten obraz raz, a następnie shardy modelu live Docker, Gateway, backendu CLI, wiązania ACP i harnessa Codex działają z `OPENCLAW_SKIP_DOCKER_BUILD=1`. Jeśli te shardy niezależnie przebudowują pełny cel źródłowy Docker, uruchomienie wydania jest błędnie skonfigurowane i zmarnuje czas zegarowy na duplikaty kompilacji obrazów.
|
||||
|
||||
## Package Acceptance
|
||||
## Akceptacja pakietu
|
||||
|
||||
Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od normalnego CI: normalne CI waliduje drzewo źródłowe, a package acceptance waliduje pojedynczy tarball przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji.
|
||||
Użyj `Package Acceptance`, gdy pytanie brzmi: „czy ten instalowalny pakiet OpenClaw działa jako produkt?”. Różni się to od zwykłego CI: zwykłe CI waliduje drzewo źródeł, podczas gdy akceptacja pakietu waliduje pojedynczy tarball przez ten sam harness Docker E2E, którego użytkownicy używają po instalacji lub aktualizacji.
|
||||
|
||||
### Zadania
|
||||
|
||||
1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, ref workflow, ref pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub.
|
||||
2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz tarballa, przygotowuje obrazy Dockera z digestem pakietu, gdy są potrzebne, i uruchamia wybrane ścieżki Dockera względem tego pakietu zamiast pakować pobraną kopię workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozdziela te ścieżki jako równoległe ukierunkowane zadania Dockera z unikalnymi artefaktami.
|
||||
3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Działa, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Package Acceptance rozwiązało pakiet; samodzielne uruchomienie Telegram nadal może instalować opublikowaną specyfikację npm.
|
||||
4. `summary` kończy workflow niepowodzeniem, jeśli rozwiązywanie pakietu, Docker acceptance lub opcjonalna ścieżka Telegram zakończyły się niepowodzeniem.
|
||||
1. `resolve_package` pobiera `workflow_ref`, rozwiązuje jednego kandydata pakietu, zapisuje `.artifacts/docker-e2e-package/openclaw-current.tgz`, zapisuje `.artifacts/docker-e2e-package/package-candidate.json`, przesyła oba jako artefakt `package-under-test` oraz wypisuje źródło, odniesienie workflow, odniesienie pakietu, wersję, SHA-256 i profil w podsumowaniu kroku GitHub.
|
||||
2. `docker_acceptance` wywołuje `openclaw-live-and-e2e-checks-reusable.yml` z `ref=workflow_ref` i `package_artifact_name=package-under-test`. Workflow wielokrotnego użytku pobiera ten artefakt, waliduje inwentarz tarballa, przygotowuje obrazy Docker z digestem pakietu, gdy są potrzebne, i uruchamia wybrane ścieżki Docker względem tego pakietu zamiast pakować checkout workflow. Gdy profil wybiera wiele ukierunkowanych `docker_lanes`, workflow wielokrotnego użytku przygotowuje pakiet i współdzielone obrazy raz, a następnie rozdziela te ścieżki jako równoległe ukierunkowane zadania Docker z unikalnymi artefaktami.
|
||||
3. `package_telegram` opcjonalnie wywołuje `NPM Telegram Beta E2E`. Działa, gdy `telegram_mode` nie jest `none`, i instaluje ten sam artefakt `package-under-test`, gdy Package Acceptance rozwiązało jeden; samodzielne uruchomienie Telegram nadal może zainstalować opublikowaną specyfikację npm.
|
||||
4. `summary` powoduje niepowodzenie workflow, jeśli rozwiązanie pakietu, akceptacja Docker albo opcjonalna ścieżka Telegram zakończyły się niepowodzeniem.
|
||||
|
||||
### Źródła kandydatów
|
||||
|
||||
- `source=npm` akceptuje tylko `openclaw@beta`, `openclaw@latest` albo dokładną wersję wydania OpenClaw, taką jak `openclaw@2026.4.27-beta.2`. Używaj tego do akceptacji opublikowanych wersji beta/stabilnych.
|
||||
- `source=ref` pakuje zaufaną gałąź, tag lub pełny SHA commita `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, weryfikuje, że wybrany commit jest osiągalny z historii gałęzi repozytorium lub tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` pobiera `.tgz` przez HTTPS; `package_sha256` jest wymagane.
|
||||
- `source=artifact` pobiera jeden `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno zostać podane dla artefaktów udostępnianych zewnętrznie.
|
||||
- `source=ref` pakuje zaufaną gałąź, tag albo pełny SHA commita `package_ref`. Resolver pobiera gałęzie/tagi OpenClaw, sprawdza, czy wybrany commit jest osiągalny z historii gałęzi repozytorium albo z tagu wydania, instaluje zależności w odłączonym worktree i pakuje go za pomocą `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` pobiera HTTPS `.tgz`; `package_sha256` jest wymagane.
|
||||
- `source=artifact` pobiera jeden `.tgz` z `artifact_run_id` i `artifact_name`; `package_sha256` jest opcjonalne, ale powinno być podane dla artefaktów udostępnianych zewnętrznie.
|
||||
|
||||
Trzymaj `workflow_ref` i `package_ref` oddzielnie. `workflow_ref` to zaufany kod workflow/harness, który uruchamia test. `package_ref` to commit źródłowy, który zostaje spakowany, gdy `source=ref`. Dzięki temu bieżący harness testowy może walidować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow.
|
||||
Trzymaj `workflow_ref` i `package_ref` oddzielnie. `workflow_ref` to zaufany kod workflow/harnessu, który uruchamia test. `package_ref` to commit źródłowy pakowany, gdy `source=ref`. Dzięki temu bieżący harness testowy może weryfikować starsze zaufane commity źródłowe bez uruchamiania starej logiki workflow.
|
||||
|
||||
### Profile zestawów
|
||||
### Profile zestawu
|
||||
|
||||
- `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
|
||||
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
|
||||
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
|
||||
- `product` — `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
|
||||
- `full` — pełne fragmenty ścieżki wydania Docker z OpenWebUI
|
||||
- `custom` — dokładne `docker_lanes`; wymagane, gdy `suite_profile=custom`
|
||||
|
||||
Profil `package` używa offline pokrycia pluginów, aby walidacja opublikowanego pakietu nie była zależna od dostępności ClawHub na żywo. Opcjonalna ścieżka Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, przy czym opublikowana ścieżka specyfikacji npm pozostaje dostępna dla samodzielnych uruchomień.
|
||||
Profil `package` używa offline pokrycia pluginów, aby walidacja opublikowanego pakietu nie zależała od dostępności ClawHub na żywo. Opcjonalna ścieżka Telegram ponownie używa artefaktu `package-under-test` w `NPM Telegram Beta E2E`, z zachowaną ścieżką specyfikacji opublikowanego npm dla samodzielnych uruchomień.
|
||||
|
||||
Kontrole wydania wywołują Package Acceptance z `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` i `telegram_mode=mock-openai`. Fragmenty Docker ścieżki wydania obejmują nakładające się ścieżki pakietu/aktualizacji/pluginów; Package Acceptance zachowuje natywny dla artefaktu dowód zgodności dołączonego kanału, offline pluginów i Telegram względem tego samego rozwiązanego tarballa pakietu. Międzyplatformowe kontrole wydania nadal obejmują specyficzne dla systemów operacyjnych wdrożenie, instalator i zachowanie platformy; walidacja produktu w zakresie pakietu/aktualizacji powinna zaczynać się od Package Acceptance. Ścieżki świeżej instalacji pakietu i instalatora Windows weryfikują też, że zainstalowany pakiet może importować nadpisanie sterowania przeglądarką z surowej bezwzględnej ścieżki Windows. Międzyplatformowy smoke zwrotu agenta OpenAI domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4-mini`, dzięki czemu dowód instalacji i Gateway pozostaje szybki oraz deterministyczny.
|
||||
Kontrole wydania wywołują Package Acceptance z `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` oraz `telegram_mode=mock-openai`. Fragmenty Docker ścieżki wydania pokrywają nakładające się ścieżki pakietu/aktualizacji/pluginów; Package Acceptance utrzymuje natywny dla artefaktu dowód zgodności bundled-channel, pluginów offline oraz Telegram względem tego samego rozwiązanego tarballa pakietu. Kontrole wydań między systemami operacyjnymi nadal obejmują specyficzne dla OS zachowanie onboardingu, instalatora i platformy; walidację produktu pakietu/aktualizacji należy zaczynać od Package Acceptance. Ścieżki świeżego pakietu i instalatora Windows sprawdzają także, czy zainstalowany pakiet może zaimportować nadpisanie browser-control z surowej bezwzględnej ścieżki Windows. Smoke między systemami operacyjnymi dla tury agenta OpenAI domyślnie używa `OPENCLAW_CROSS_OS_OPENAI_MODEL`, gdy jest ustawione, w przeciwnym razie `openai/gpt-5.4-mini`, aby dowód instalacji i Gateway pozostał szybki oraz deterministyczny.
|
||||
|
||||
### Okna zgodności ze starszymi wersjami
|
||||
|
||||
Package Acceptance ma ograniczone okna zgodności ze starszymi wersjami dla już opublikowanych pakietów. Pakiety do `2026.4.25` włącznie, w tym `2026.4.25-beta.*`, mogą używać ścieżki zgodności:
|
||||
|
||||
- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać na pliki pominięte w tarballu;
|
||||
- znane prywatne wpisy QA w `dist/postinstall-inventory.json` mogą wskazywać pliki pominięte w tarballu;
|
||||
- `doctor-switch` może pominąć podprzypadek utrwalania `gateway install --wrapper`, gdy pakiet nie udostępnia tej flagi;
|
||||
- `update-channel-switch` może przyciąć brakujące `pnpm.patchedDependencies` z fałszywej fixture git pochodzącej z tarballa i może logować brakujące utrwalone `update.channel`;
|
||||
- smoki pluginów mogą odczytywać starsze lokalizacje rekordów instalacji albo akceptować brak utrwalania rekordu instalacji marketplace;
|
||||
- `update-channel-switch` może przyciąć brakujące `pnpm.patchedDependencies` z fałszywego fixture git pochodzącego z tarballa i może logować brakujące utrwalone `update.channel`;
|
||||
- smoke testy pluginów mogą czytać starsze lokalizacje rekordów instalacji albo akceptować brak utrwalenia rekordu instalacji z marketplace;
|
||||
- `plugin-update` może zezwolić na migrację metadanych konfiguracji, nadal wymagając, aby rekord instalacji i zachowanie bez ponownej instalacji pozostały niezmienione.
|
||||
|
||||
Opublikowany pakiet `2026.4.26` może też ostrzegać o plikach znaczników metadanych lokalnej kompilacji, które zostały już wydane. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki kończą się niepowodzeniem zamiast ostrzeżeniem lub pominięciem.
|
||||
Opublikowany pakiet `2026.4.26` może także ostrzegać o plikach stempli metadanych lokalnego builda, które zostały już dostarczone. Późniejsze pakiety muszą spełniać nowoczesne kontrakty; te same warunki powodują błąd zamiast ostrzeżenia albo pominięcia.
|
||||
|
||||
### Przykłady
|
||||
|
||||
@ -238,152 +238,152 @@ gh workflow run package-acceptance.yml \
|
||||
-f docker_lanes='install-e2e plugin-update'
|
||||
```
|
||||
|
||||
Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź podrzędne uruchomienie `docker_acceptance` oraz jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi ścieżek, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu lub dokładnych ścieżek Docker zamiast ponownego uruchamiania pełnej walidacji wydania.
|
||||
Podczas debugowania nieudanego uruchomienia akceptacji pakietu zacznij od podsumowania `resolve_package`, aby potwierdzić źródło pakietu, wersję i SHA-256. Następnie sprawdź uruchomienie potomne `docker_acceptance` i jego artefakty Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, logi ścieżek, czasy faz i polecenia ponownego uruchomienia. Preferuj ponowne uruchomienie nieudanego profilu pakietu albo dokładnych ścieżek Docker zamiast ponownego uruchamiania pełnej walidacji wydania.
|
||||
|
||||
## Smoke instalacji
|
||||
|
||||
Oddzielny workflow `Install Smoke` ponownie używa tego samego skryptu zakresu przez własne zadanie `preflight`. Dzieli pokrycie smoke na `run_fast_install_smoke` i `run_full_install_smoke`.
|
||||
|
||||
- **Szybka ścieżka** działa dla pull requestów dotykających powierzchni Docker/pakietu, zmian pakietu/manifestu dołączonego pluginu albo powierzchni rdzeniowego pluginu/kanału/Gateway/Plugin SDK, które wykonują zadania smoke Docker. Zmiany wyłącznie źródłowe w dołączonych pluginach, edycje wyłącznie testów i edycje wyłącznie dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia smoke CLI usuwania agentów ze współdzielonego workspace, uruchamia kontenerowe e2e gateway-network, weryfikuje argument kompilacji dołączonego rozszerzenia i uruchamia ograniczony profil Docker dołączonego pluginu w ramach 240-sekundowego łącznego limitu czasu polecenia (każde uruchomienie Docker scenariusza jest limitowane osobno).
|
||||
- **Pełna ścieżka** utrzymuje instalację pakietu QR i pokrycie Docker instalatora/aktualizacji dla nocnych zaplanowanych uruchomień, ręcznych uruchomień, kontroli wydania workflow-call oraz pull requestów, które rzeczywiście dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje lub ponownie używa jednego obrazu GHCR smoke głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, smoki głównego Dockerfile/Gateway, smoki instalatora/aktualizacji oraz szybkie Docker E2E dołączonego pluginu jako oddzielne zadania, aby praca instalatora nie czekała za smokami obrazu głównego.
|
||||
- **Szybka ścieżka** uruchamia się dla pull requestów dotykających powierzchni Docker/pakietu, zmian pakietu/manifestu bundled pluginów albo powierzchni core plugin/channel/gateway/Plugin SDK, które wykonują zadania smoke Docker. Zmiany wyłącznie źródłowe w bundled pluginach, edycje tylko testów i edycje tylko dokumentacji nie rezerwują workerów Docker. Szybka ścieżka buduje obraz głównego Dockerfile raz, sprawdza CLI, uruchamia smoke CLI usuwania współdzielonego workspace agentów, uruchamia kontenerowy e2e gateway-network, weryfikuje argument builda bundled extension i uruchamia ograniczony profil Docker bundled-plugin w ramach 240-sekundowego łącznego limitu czasu polecenia (każde uruchomienie Docker scenariusza jest ograniczone osobno).
|
||||
- **Pełna ścieżka** zachowuje instalację pakietu QR oraz pokrycie Docker instalatora/aktualizacji dla nocnych uruchomień harmonogramu, ręcznych uruchomień, kontroli wydań przez workflow-call i pull requestów, które faktycznie dotykają powierzchni instalatora/pakietu/Docker. W trybie pełnym install-smoke przygotowuje albo ponownie używa jednego obrazu smoke GHCR głównego Dockerfile dla docelowego SHA, a następnie uruchamia instalację pakietu QR, smoke testy głównego Dockerfile/Gateway, smoke testy instalatora/aktualizacji oraz szybkie Docker E2E bundled-plugin jako osobne zadania, aby praca instalatora nie czekała za smoke testami obrazu głównego.
|
||||
|
||||
Push do `main` (w tym commity merge) nie wymuszają pełnej ścieżki; gdy logika zakresu zmian żądałaby pełnego pokrycia przy pushu, workflow zachowuje szybki smoke Docker i pozostawia pełny smoke instalacji walidacji nocnej lub wydania.
|
||||
Push’e do `main` (w tym commity merge) nie wymuszają pełnej ścieżki; gdy logika zakresu zmian zażądałaby pełnego pokrycia przy pushu, workflow zachowuje szybki smoke Docker i pozostawia pełny install smoke walidacji nocnej albo wydaniowej.
|
||||
|
||||
Wolny smoke dostawcy obrazu z globalną instalacją Bun jest bramkowany osobno przez `run_bun_global_install_smoke`. Działa w harmonogramie nocnym i z workflow kontroli wydania, a ręczne uruchomienia `Install Smoke` mogą go włączyć, ale pull requesty i pushe do `main` nie. Testy Docker QR i instalatora zachowują własne Dockerfile skoncentrowane na instalacji.
|
||||
Wolny smoke globalnej instalacji Bun dla image-provider jest osobno bramkowany przez `run_bun_global_install_smoke`. Uruchamia się w nocnym harmonogramie i z workflow kontroli wydań, a ręczne uruchomienia `Install Smoke` mogą go włączyć, ale pull requesty i push’e do `main` nie. Testy Docker QR i instalatora zachowują własne instalacyjne Dockerfile.
|
||||
|
||||
## Lokalne Docker E2E
|
||||
|
||||
`pnpm test:docker:all` wstępnie buduje jeden współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`:
|
||||
`pnpm test:docker:all` prebuduje jeden współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm i buduje dwa współdzielone obrazy `scripts/e2e/Dockerfile`:
|
||||
|
||||
- czysty runner Node/Git dla ścieżek instalatora/aktualizacji/zależności pluginów;
|
||||
- obraz funkcjonalny, który instaluje ten sam tarball w `/app` dla zwykłych ścieżek funkcjonalności.
|
||||
- surowy runner Node/Git dla ścieżek instalatora/aktualizacji/zależności pluginów;
|
||||
- funkcjonalny obraz, który instaluje ten sam tarball do `/app` dla normalnych ścieżek funkcjonalnych.
|
||||
|
||||
Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planisty w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Scheduler wybiera obraz dla każdej ścieżki za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia ścieżki z `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`, logika planera w `scripts/lib/docker-e2e-plan.mjs`, a runner wykonuje tylko wybrany plan. Scheduler wybiera obraz dla ścieżki za pomocą `OPENCLAW_DOCKER_E2E_BARE_IMAGE` i `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, a następnie uruchamia ścieżki z `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
|
||||
### Parametry dostrajania
|
||||
|
||||
| Zmienna | Domyślnie | Cel |
|
||||
| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Liczba slotów głównej puli dla zwykłych ścieżek. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Liczba slotów puli końcowej wrażliwej na dostawców. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limit równoczesnych ścieżek live, aby dostawcy nie ograniczali przepustowości. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limit równoczesnych ścieżek instalacji npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limit równoczesnych ścieżek wielousługowych. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Odstęp między startami ścieżek, aby uniknąć burz tworzenia przez demona Docker; ustaw `0`, aby wyłączyć odstęp. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Zapasowy limit czasu na ścieżkę (120 minut); wybrane ścieżki live/końcowe używają ciaśniejszych limitów. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | nieustawione | `1` wypisuje plan schedulera bez uruchamiania ścieżek. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | nieustawione | Lista dokładnych ścieżek rozdzielona przecinkami; pomija smoke czyszczenia, aby agenci mogli odtworzyć jedną nieudaną ścieżkę. |
|
||||
| Variable | Default | Purpose |
|
||||
| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Liczba slotów puli głównej dla normalnych ścieżek. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Liczba slotów puli końcowej wrażliwej na dostawców. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Limit równoczesnych ścieżek live, aby dostawcy nie throttlowali. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Limit równoczesnych ścieżek instalacji npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Limit równoczesnych ścieżek wielousługowych. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Odstęp między startami ścieżek, aby uniknąć burz tworzenia w daemonie Docker; ustaw `0`, aby wyłączyć odstęp. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Zapasowy limit czasu na ścieżkę (120 minut); wybrane ścieżki live/tail używają ciaśniejszych limitów. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` wypisuje plan schedulera bez uruchamiania ścieżek. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Rozdzielona przecinkami dokładna lista ścieżek; pomija cleanup smoke, aby agenci mogli odtworzyć jedną nieudaną ścieżkę. |
|
||||
|
||||
Ścieżka cięższa niż jej efektywny limit nadal może wystartować z pustej puli, a następnie działa sama, dopóki nie zwolni pojemności. Lokalny agregat wykonuje preflight Docker, usuwa przestarzałe kontenery OpenClaw E2E, emituje status aktywnych ścieżek, utrwala czasy ścieżek do porządkowania od najdłuższych i domyślnie zatrzymuje planowanie nowych ścieżek z puli po pierwszym niepowodzeniu.
|
||||
Ścieżka cięższa niż jej efektywny limit może nadal wystartować z pustej puli, a następnie działa sama, dopóki nie zwolni pojemności. Lokalny agregat wykonuje preflight Docker, usuwa przestarzałe kontenery OpenClaw E2E, emituje status aktywnych ścieżek, utrwala czasy ścieżek dla kolejności od najdłuższych i domyślnie przestaje planować nowe ścieżki z puli po pierwszym błędzie.
|
||||
|
||||
### Wielokrotnego użytku workflow live/E2E
|
||||
|
||||
Wielokrotnego użytku workflow live/E2E pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, ścieżka i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inwentarz tarballa; buduje i wypycha tagowane digestem pakietu obrazy GHCR Docker E2E bare/functional przez cache warstw Docker Blacksmith, gdy plan potrzebuje ścieżek z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` lub istniejących obrazów z digestem pakietu zamiast przebudowy. Pobierania obrazów Docker są ponawiane z ograniczonym 180-sekundowym limitem czasu na próbę, aby zablokowany strumień registry/cache był szybko ponawiany zamiast zużywać większość krytycznej ścieżki CI.
|
||||
Wielokrotnego użytku workflow live/E2E pyta `scripts/test-docker-all.mjs --plan-json`, jaki pakiet, rodzaj obrazu, obraz live, ścieżka i pokrycie poświadczeń są wymagane. `scripts/docker-e2e.mjs` następnie konwertuje ten plan na wyjścia i podsumowania GitHub. Albo pakuje OpenClaw przez `scripts/package-openclaw-for-docker.mjs`, pobiera artefakt pakietu z bieżącego uruchomienia, albo pobiera artefakt pakietu z `package_artifact_run_id`; waliduje inventory tarballa; buduje i wypycha tagowane digestem pakietu obrazy bare/functional GHCR Docker E2E przez cache warstw Docker Blacksmith, gdy plan potrzebuje ścieżek z zainstalowanym pakietem; oraz ponownie używa podanych wejść `docker_e2e_bare_image`/`docker_e2e_functional_image` albo istniejących obrazów z digestem pakietu zamiast przebudowywać. Pobrania obrazów Docker są ponawiane z ograniczonym 180-sekundowym limitem czasu na próbę, aby zablokowany strumień registry/cache szybko ponowił próbę zamiast zużywać większość ścieżki krytycznej CI.
|
||||
|
||||
### Fragmenty ścieżki wydania
|
||||
|
||||
Pokrycie Docker wydania uruchamia mniejsze pofragmentowane zadania z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko potrzebny rodzaj obrazu i wykonywał wiele ścieżek przez ten sam ważony scheduler:
|
||||
Pokrycie Docker wydania uruchamia mniejsze fragmentowane zadania z `OPENCLAW_SKIP_DOCKER_BUILD=1`, aby każdy fragment pobierał tylko potrzebny rodzaj obrazu i wykonywał wiele ścieżek przez ten sam ważony scheduler:
|
||||
|
||||
- `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
|
||||
- `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels`
|
||||
|
||||
Bieżące części wydania Docker to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, od `plugins-runtime-install-a` do `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` oraz `bundled-channels-contracts`. Zbiorcza część `bundled-channels` pozostaje dostępna do ręcznych, jednorazowych ponownych uruchomień, a `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zbiorczymi aliasami plugin/runtime. Alias linii `install-e2e` pozostaje zbiorczym aliasem ręcznego ponownego uruchomienia dla obu linii instalatorów dostawców. Część `bundled-channels` uruchamia podzielone linie `bundled-channel-*` i `bundled-channel-update-*` zamiast szeregowej, całościowej linii `bundled-channel-deps`.
|
||||
Obecne fragmenty Docker wydania to `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, od `plugins-runtime-install-a` do `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` oraz `bundled-channels-contracts`. Zbiorczy fragment `bundled-channels` pozostaje dostępny do ręcznych, jednorazowych ponowień, a `plugins-runtime-core`, `plugins-runtime` i `plugins-integrations` pozostają zbiorczymi aliasami Plugin/runtime. Alias pasa `install-e2e` pozostaje zbiorczym aliasem ręcznego ponowienia dla obu pasów instalatora dostawców. Fragment `bundled-channels` uruchamia podzielone pasy `bundled-channel-*` i `bundled-channel-update-*` zamiast szeregowego pasa all-in-one `bundled-channel-deps`.
|
||||
|
||||
OpenWebUI jest włączany do `plugins-runtime-services`, gdy wymaga tego pełne pokrycie ścieżki wydania, i zachowuje samodzielną część `openwebui` tylko dla uruchomień dotyczących wyłącznie OpenWebUI. Linie aktualizacji kanałów w pakiecie ponawiają próbę raz w przypadku przejściowych awarii sieci npm.
|
||||
OpenWebUI jest włączany do `plugins-runtime-services`, gdy wymaga tego pełne pokrycie ścieżki wydania, i zachowuje samodzielny fragment `openwebui` tylko dla wywołań dotyczących wyłącznie OpenWebUI. Pasy aktualizacji kanałów wbudowanych ponawiają próbę raz w przypadku przejściowych awarii sieci npm.
|
||||
|
||||
Każda część przesyła `.artifacts/docker-tests/` z dziennikami linii, czasami, `summary.json`, `failures.json`, czasami faz, JSON planu harmonogramu, tabelami wolnych linii i poleceniami ponownego uruchomienia dla poszczególnych linii. Wejście workflow `docker_lanes` uruchamia wybrane linie względem przygotowanych obrazów zamiast zadań części, dzięki czemu debugowanie nieudanych linii jest ograniczone do jednego ukierunkowanego zadania Docker i przygotowuje, pobiera albo ponownie używa artefaktu pakietu dla tego uruchomienia; jeśli wybrana linia jest linią live Docker, ukierunkowane zadanie buduje lokalnie obraz testów live na potrzeby tego ponownego uruchomienia. Wygenerowane polecenia GitHub ponownego uruchomienia dla poszczególnych linii zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, dzięki czemu nieudana linia może ponownie użyć dokładnie tego pakietu i tych obrazów z nieudanego uruchomienia.
|
||||
Każdy fragment przesyła `.artifacts/docker-tests/` z logami pasów, czasami, `summary.json`, `failures.json`, czasami faz, JSON planu harmonogramu, tabelami wolnych pasów i poleceniami ponownego uruchomienia dla poszczególnych pasów. Wejście workflow `docker_lanes` uruchamia wybrane pasy względem przygotowanych obrazów zamiast zadań fragmentów, co ogranicza debugowanie pasa z błędem do jednego docelowego zadania Docker i przygotowuje, pobiera lub ponownie wykorzystuje artefakt pakietu dla tego uruchomienia; jeśli wybrany pas jest pasem live Docker, docelowe zadanie buduje lokalnie obraz live-test dla tego ponowienia. Wygenerowane polecenia GitHub do ponowienia dla poszczególnych pasów zawierają `package_artifact_run_id`, `package_artifact_name` i wejścia przygotowanych obrazów, gdy te wartości istnieją, dzięki czemu pas z błędem może ponownie użyć dokładnie tego pakietu i tych obrazów z nieudanego uruchomienia.
|
||||
|
||||
```bash
|
||||
pnpm test:docker:rerun <run-id> # download Docker artifacts and print combined/per-lane targeted rerun commands
|
||||
pnpm test:docker:timings <summary> # slow-lane and phase critical-path summaries
|
||||
```
|
||||
|
||||
Zaplanowany workflow live/E2E uruchamia codziennie pełny zestaw Docker dla ścieżki wydania.
|
||||
Zaplanowany workflow live/E2E codziennie uruchamia pełny zestaw Docker ścieżki wydania.
|
||||
|
||||
## Wersja przedpremierowa Plugin
|
||||
## Przedpremiera Plugin
|
||||
|
||||
`Plugin Prerelease` zapewnia droższe pokrycie produktu/pakietu, więc jest osobnym workflow uruchamianym przez `Full Release Validation` albo przez jawnego operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne uruchomienia CI nie włączają tego zestawu. Równoważy testy Plugin w pakiecie między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają do dwóch grup konfiguracji Plugin naraz, z jednym workerem Vitest na grupę i większą stertą Node, aby partie Plugin intensywnie importujące moduły nie tworzyły dodatkowych zadań CI.
|
||||
`Plugin Prerelease` zapewnia droższe pokrycie produktu/pakietu, dlatego jest osobnym workflow wywoływanym przez `Full Release Validation` albo jawnie przez operatora. Zwykłe pull requesty, wypchnięcia do `main` i samodzielne ręczne wywołania CI nie uruchamiają tego zestawu. Równoważy testy wbudowanych Plugin między ośmioma workerami rozszerzeń; te zadania shardów rozszerzeń uruchamiają do dwóch grup konfiguracji Plugin naraz, z jednym workerem Vitest na grupę i większą stertą Node, aby partie Plugin intensywnie używające importów nie tworzyły dodatkowych zadań CI.
|
||||
|
||||
## QA Lab
|
||||
|
||||
QA Lab ma dedykowane linie CI poza głównym workflow o inteligentnym zakresie.
|
||||
QA Lab ma dedykowane pasy CI poza głównym workflow o inteligentnym zakresie.
|
||||
|
||||
- Workflow `Parity gate` uruchamia się przy pasujących zmianach PR i ręcznym uruchomieniu; buduje prywatne środowisko uruchomieniowe QA i porównuje agentowe pakiety mock GPT-5.5 oraz Opus 4.6.
|
||||
- Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` i przy ręcznym uruchomieniu; rozdziela bramkę parytetu mock, linię live Matrix oraz linie live Telegram i Discord jako zadania równoległe. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex.
|
||||
- Workflow `Parity gate` uruchamia się przy pasujących zmianach PR i ręcznym wywołaniu; buduje prywatny runtime QA i porównuje mockowe pakiety agentowe GPT-5.5 oraz Opus 4.6.
|
||||
- Workflow `QA-Lab - All Lanes` uruchamia się co noc na `main` i przy ręcznym wywołaniu; rozdziela mockową bramkę parzystości, live pas Matrix oraz live pasy Telegram i Discord jako równoległe zadania. Zadania live używają środowiska `qa-live-shared`, a Telegram/Discord używają dzierżaw Convex.
|
||||
|
||||
Kontrole wydania uruchamiają linie transportu live Matrix i Telegram z deterministycznym dostawcą mock oraz modelami kwalifikowanymi jako mock (`mock-openai/gpt-5.5` i `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień modelu live i normalnego uruchamiania Plugin dostawcy. Gateway transportu live wyłącza wyszukiwanie pamięci, ponieważ parytet QA obejmuje zachowanie pamięci osobno; łączność dostawcy jest obejmowana przez osobne zestawy modelu live, natywnego dostawcy i dostawcy Docker.
|
||||
Kontrole wydania uruchamiają live pasy transportu Matrix i Telegram z deterministycznym mockowym dostawcą oraz modelami zakwalifikowanymi jako mock (`mock-openai/gpt-5.5` i `mock-openai/gpt-5.5-alt`), aby kontrakt kanału był odizolowany od opóźnień live modelu i normalnego uruchamiania provider-plugin. Live transport gateway wyłącza wyszukiwanie pamięci, ponieważ parzystość QA osobno obejmuje zachowanie pamięci; łączność dostawcy jest objęta osobnymi zestawami live model, native provider i Docker provider.
|
||||
|
||||
Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy sprawdzony CLI to obsługuje. Domyślna wartość CLI i ręczne wejście workflow pozostają `all`; ręczne uruchomienie `matrix_profile=all` zawsze dzieli pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`.
|
||||
Matrix używa `--profile fast` dla zaplanowanych bramek i bramek wydania, dodając `--fail-fast` tylko wtedy, gdy obsługuje to sprawdzony CLI. Domyślna wartość CLI i ręczne wejście workflow pozostają `all`; ręczne wywołanie `matrix_profile=all` zawsze dzieli pełne pokrycie Matrix na zadania `transport`, `media`, `e2ee-smoke`, `e2ee-deep` i `e2ee-cli`.
|
||||
|
||||
`OpenClaw Release Checks` uruchamia też krytyczne dla wydania linie QA Lab przed zatwierdzeniem wydania; jego bramka parytetu QA uruchamia pakiety kandydujące i bazowe jako równoległe zadania linii, a następnie pobiera oba artefakty do małego zadania raportującego na potrzeby końcowego porównania parytetu.
|
||||
`OpenClaw Release Checks` uruchamia również krytyczne dla wydania pasy QA Lab przed zatwierdzeniem wydania; jego bramka parzystości QA uruchamia pakiety kandydata i bazowe jako równoległe zadania pasów, a następnie pobiera oba artefakty do małego zadania raportu na potrzeby końcowego porównania parzystości.
|
||||
|
||||
Nie umieszczaj ścieżki lądowania PR za `Parity gate`, chyba że zmiana rzeczywiście dotyka środowiska uruchomieniowego QA, parytetu pakietów modeli albo powierzchni, którą posiada workflow parytetu. W przypadku zwykłych poprawek kanałów, konfiguracji, dokumentacji albo testów jednostkowych traktuj to jako opcjonalny sygnał i kieruj się dowodami z CI/kontroli o odpowiednim zakresie.
|
||||
Nie umieszczaj ścieżki lądowania PR za `Parity gate`, chyba że zmiana rzeczywiście dotyka runtime QA, parzystości pakietów modeli albo powierzchni należącej do workflow parzystości. W przypadku zwykłych poprawek kanałów, konfiguracji, dokumentacji lub testów jednostkowych traktuj to jako opcjonalny sygnał i korzystaj z dowodów z właściwego zakresu CI/kontroli.
|
||||
|
||||
## CodeQL
|
||||
|
||||
Workflow `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przebiegu, a nie pełnym przeglądem repozytorium. Codzienne, ręczne i ochronne uruchomienia pull requestów innych niż wersje robocze skanują kod workflow Actions oraz powierzchnie JavaScript/TypeScript o najwyższym ryzyku, używając zapytań bezpieczeństwa o wysokiej pewności filtrowanych do wysokiego/krytycznego `security-severity`.
|
||||
Workflow `CodeQL` jest celowo wąskim skanerem bezpieczeństwa pierwszego przejścia, a nie pełnym przeglądem repozytorium. Codzienne, ręczne oraz ochronne uruchomienia dla pull requestów innych niż szkic skanują kod workflow Actions oraz powierzchnie JavaScript/TypeScript najwyższego ryzyka za pomocą zapytań bezpieczeństwa o wysokiej pewności, filtrowanych do `security-severity` high/critical.
|
||||
|
||||
Ochrona pull requestów pozostaje lekka: uruchamia się tylko dla zmian w `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i uruchamia tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany workflow. Android i macOS CodeQL pozostają poza domyślnymi ustawieniami PR.
|
||||
Ochrona pull requestów pozostaje lekka: uruchamia się tylko dla zmian pod `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` lub `src` i wykonuje tę samą macierz bezpieczeństwa o wysokiej pewności co zaplanowany workflow. Android i macOS CodeQL pozostają poza domyślnymi PR.
|
||||
|
||||
### Kategorie bezpieczeństwa
|
||||
|
||||
| Kategoria | Powierzchnia |
|
||||
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | Uwierzytelnianie, sekrety, piaskownica, cron i bazowy Gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Kontrakty implementacji kanałów core oraz środowisko uruchomieniowe Plugin kanałów, Gateway, Plugin SDK, sekrety, punkty styku audytu |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Powierzchnie core SSRF, parsowanie IP, straż sieciowa, web-fetch oraz polityka SSRF Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, pomocniki wykonywania procesów, dostarczanie wychodzące i bramki wykonywania narzędzi agentów |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Instalacja Plugin, loader, manifest, rejestr, staging zależności runtime, ładowanie źródeł i powierzchnie zaufania kontraktu pakietu Plugin SDK |
|
||||
| `/codeql-security-high/core-auth-secrets` | Auth, sekrety, sandbox, cron i bazowy gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Kontrakty implementacji kanałów core oraz runtime Plugin kanału, gateway, Plugin SDK, sekrety, punkty styku audytu |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Powierzchnie core SSRF, parsowania IP, ochrony sieci, web-fetch i polityki SSRF Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | Serwery MCP, helpery wykonywania procesów, dostarczanie wychodzące i bramki wykonywania narzędzi agenta |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Instalacja Plugin, loader, manifest, registry, etapowanie zależności runtime, ładowanie źródeł i powierzchnie zaufania kontraktu pakietu Plugin SDK |
|
||||
|
||||
### Shardy bezpieczeństwa specyficzne dla platform
|
||||
|
||||
- `CodeQL Android Critical Security` — zaplanowany shard bezpieczeństwa Android. Buduje aplikację Android ręcznie dla CodeQL na najmniejszym runnerze Blacksmith Linux akceptowanym przez workflow sanity. Przesyła pod `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — tygodniowy/ręczny shard bezpieczeństwa macOS. Buduje aplikację macOS ręcznie dla CodeQL na Blacksmith macOS, filtruje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Trzymany poza codziennymi domyślnymi ustawieniami, ponieważ kompilacja macOS dominuje czas działania nawet wtedy, gdy jest czysta.
|
||||
- `CodeQL macOS Critical Security` — tygodniowy/ręczny shard bezpieczeństwa macOS. Buduje aplikację macOS ręcznie dla CodeQL na Blacksmith macOS, odfiltrowuje wyniki budowania zależności z przesyłanego SARIF i przesyła pod `/codeql-critical-security/macos`. Utrzymywany poza codziennymi domyślnymi uruchomieniami, ponieważ budowanie macOS dominuje czas wykonania nawet przy czystym stanie.
|
||||
|
||||
### Kategorie jakości krytycznej
|
||||
|
||||
`CodeQL Critical Quality` to odpowiadający shard niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o ważności błędu, niezwiązane z bezpieczeństwem, na wąskich powierzchniach o wysokiej wartości na mniejszym runnerze Blacksmith Linux. Jego ochrona pull requestów jest celowo mniejsza niż zaplanowany profil: PR-y inne niż wersje robocze uruchamiają tylko odpowiadające shardy `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` i `plugin-sdk-reply-runtime` dla zmian w kodzie wykonywania poleceń/modeli/narzędzi agenta i wysyłania odpowiedzi, kodzie schematów/migracji/IO konfiguracji, kodzie uwierzytelniania/sekretów/piaskownicy/bezpieczeństwa, core kanału i środowisku uruchomieniowym Plugin kanałów w pakiecie, protokole Gateway/metodach serwera, spoiwie runtime/SDK pamięci, MCP/procesie/dostarczaniu wychodzącym, runtime dostawcy/katalogu modeli, diagnostyce sesji/kolejkach dostarczania, loaderze Plugin, kontrakcie Plugin SDK/pakietu albo runtime odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i workflow jakości uruchamiają wszystkie dwanaście shardów jakości PR.
|
||||
`CodeQL Critical Quality` to odpowiadający shard niezwiązany z bezpieczeństwem. Uruchamia tylko zapytania jakości JavaScript/TypeScript o poziomie błędu i niezwiązane z bezpieczeństwem, na wąskich powierzchniach o wysokiej wartości, na mniejszym runnerze Blacksmith Linux. Jego ochrona pull requestów jest celowo mniejsza niż profil zaplanowany: PR inne niż szkic uruchamiają tylko pasujące shardy `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` i `plugin-sdk-reply-runtime` dla zmian w kodzie poleceń/modeli/wykonywania narzędzi agenta i dyspozycji odpowiedzi, kodzie schematu/migracji/IO konfiguracji, kodzie auth/sekretów/sandboxu/bezpieczeństwa, core channel i runtime wbudowanych channel plugin, gateway protocol/server-method, runtime pamięci/spoiwie SDK, MCP/procesie/dostarczaniu wychodzącym, runtime dostawcy/katalogu modeli, diagnostyce sesji/kolejkach dostarczania, loaderze Plugin, Plugin SDK/kontrakcie pakietu albo runtime odpowiedzi Plugin SDK. Zmiany konfiguracji CodeQL i workflow jakości uruchamiają wszystkie dwanaście shardów jakości PR.
|
||||
|
||||
Ręczne uruchomienie akceptuje:
|
||||
Ręczne wywołanie akceptuje:
|
||||
|
||||
```
|
||||
profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
```
|
||||
|
||||
Wąskie profile są punktami zaczepienia do nauki/iteracji, służącymi do uruchamiania jednego sharda jakości w izolacji.
|
||||
Wąskie profile są zaczepami szkoleniowymi/iteracyjnymi do uruchamiania jednego shardu jakości w izolacji.
|
||||
|
||||
| Kategoria | Powierzchnia |
|
||||
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Uwierzytelnianie, sekrety, piaskownica, Cron oraz kod granicy zabezpieczeń Gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | Schemat konfiguracji, migracja, normalizacja oraz kontrakty IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Schematy protokołu Gateway oraz kontrakty metod serwera |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Kontrakty implementacji kanału rdzenia oraz dołączonego Plugin kanału |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Wykonywanie poleceń, dyspozycja modeli/dostawców, dyspozycja i kolejki automatycznych odpowiedzi oraz kontrakty środowiska wykonawczego płaszczyzny sterowania ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędzi, pomocniki nadzoru procesów oraz kontrakty dostarczania wychodzącego |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK hosta pamięci, fasady środowiska wykonawczego pamięci, aliasy SDK Plugin pamięci, warstwa aktywacji środowiska wykonawczego pamięci oraz polecenia doctor pamięci |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzna logika kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie pakietów zdarzeń/logów diagnostycznych oraz kontrakty CLI doctor sesji |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dyspozycja odpowiedzi przychodzących SDK Plugin, pomocniki ładunku odpowiedzi/fragmentacji/środowiska wykonawczego, opcje odpowiedzi kanału, kolejki dostarczania oraz pomocniki wiązania sesji/wątku |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Normalizacja katalogu modeli, uwierzytelnianie i odkrywanie dostawców, rejestracja środowiska wykonawczego dostawców, domyślne ustawienia/katalogi dostawców oraz rejestry web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Bootstrap interfejsu sterowania, lokalna trwałość danych, przepływy sterowania Gateway oraz kontrakty środowiska wykonawczego płaszczyzny sterowania zadań |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Kontrakty środowiska wykonawczego bazowego pobierania/wyszukiwania WWW, IO mediów, rozumienia mediów, generowania obrazów oraz generowania mediów |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Kontrakty punktów wejścia loadera, rejestru, powierzchni publicznej oraz SDK Plugin |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Opublikowane źródło SDK Plugin po stronie pakietu oraz pomocniki kontraktu pakietu Plugin |
|
||||
| Kategoria | Powierzchnia |
|
||||
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Kod granicy bezpieczeństwa Auth, sekretów, piaskownicy, Cron i Gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | Schemat konfiguracji, migracja, normalizacja i kontrakty IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Schematy protokołu Gateway i kontrakty metod serwera |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Kontrakty implementacji głównego kanału i dołączonego kanału Plugin |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Wykonywanie poleceń, dyspozycja modeli/dostawców, dyspozycja i kolejki automatycznych odpowiedzi oraz kontrakty środowiska wykonawczego płaszczyzny sterowania ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | Serwery MCP i mosty narzędziowe, pomocniki nadzoru procesów oraz kontrakty dostarczania wychodzącego |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK hosta pamięci, fasady środowiska wykonawczego pamięci, aliasy SDK pamięci Plugin, kod wiążący aktywację środowiska wykonawczego pamięci oraz polecenia doctor pamięci |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Wewnętrzne elementy kolejki odpowiedzi, kolejki dostarczania sesji, pomocniki wiązania/dostarczania sesji wychodzących, powierzchnie pakietów zdarzeń/logów diagnostycznych oraz kontrakty CLI doctor sesji |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dyspozycja odpowiedzi przychodzących w SDK Plugin, pomocniki ładunków/kawałkowania/środowiska wykonawczego odpowiedzi, opcje odpowiedzi kanału, kolejki dostarczania oraz pomocniki wiązania sesji/wątków |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Normalizacja katalogu modeli, uwierzytelnianie i wykrywanie dostawców, rejestracja środowiska wykonawczego dostawców, domyślne ustawienia/katalogi dostawców oraz rejestry web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Inicjalizacja Control UI, lokalna trwałość danych, przepływy sterowania Gateway oraz kontrakty środowiska wykonawczego płaszczyzny sterowania zadaniami |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Kontrakty środowiska wykonawczego głównego pobierania/wyszukiwania w sieci, IO multimediów, rozumienia multimediów, generowania obrazów i generowania multimediów |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Kontrakty loadera, rejestru, powierzchni publicznej i punktów wejścia SDK Plugin |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Opublikowane źródło SDK Plugin po stronie pakietu i pomocniki kontraktu pakietu Plugin |
|
||||
|
||||
Jakość pozostaje oddzielona od bezpieczeństwa, aby ustalenia jakościowe można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Python i dołączonych Plugin należy dodać ponownie jako zawężone lub podzielone na odłamki prace następcze dopiero wtedy, gdy wąskie profile będą miały stabilne środowisko wykonawcze i sygnał.
|
||||
Jakość pozostaje oddzielona od bezpieczeństwa, aby ustalenia jakościowe można było planować, mierzyć, wyłączać lub rozszerzać bez zaciemniania sygnału bezpieczeństwa. Rozszerzenie CodeQL dla Swift, Python i dołączonych Plugin powinno zostać ponownie dodane jako zakresowane lub shardowane prace następcze dopiero po ustabilizowaniu środowiska wykonawczego i sygnału w wąskich profilach.
|
||||
|
||||
## Przepływy prac utrzymaniowych
|
||||
## Przepływy utrzymania
|
||||
|
||||
### Docs Agent
|
||||
### Agent dokumentacji
|
||||
|
||||
Przepływ pracy `Docs Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex służąca utrzymywaniu istniejącej dokumentacji w zgodności z niedawno wylądowanymi zmianami. Nie ma czystego harmonogramu: może go wyzwolić udane uruchomienie CI po wypchnięciu przez użytkownika innego niż bot do `main`, a ręczne wywołanie może uruchomić go bezpośrednio. Wywołania przez workflow-run są pomijane, gdy `main` przesunął się dalej albo gdy w ostatniej godzinie utworzono inne niepominięte uruchomienie Docs Agent. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego źródłowego SHA Docs Agent do bieżącego `main`, więc jedno godzinowe uruchomienie może objąć wszystkie zmiany w main nagromadzone od ostatniego przejścia przez dokumentację.
|
||||
Workflow `Docs Agent` to sterowana zdarzeniami ścieżka utrzymania Codex, która utrzymuje istniejącą dokumentację w zgodności z niedawno wprowadzonymi zmianami. Nie ma czystego harmonogramu: udane uruchomienie CI dla wypchnięcia na `main` przez użytkownika innego niż bot może ją wyzwolić, a ręczne wywołanie może uruchomić ją bezpośrednio. Wywołania workflow-run są pomijane, gdy `main` przesunął się dalej albo gdy w ostatniej godzinie utworzono inne niepominięte uruchomienie Docs Agent. Gdy działa, przegląda zakres commitów od poprzedniego niepominiętego źródłowego SHA Docs Agent do bieżącego `main`, więc jedno godzinne uruchomienie może objąć wszystkie zmiany na main zgromadzone od ostatniego przebiegu dokumentacji.
|
||||
|
||||
### Test Performance Agent
|
||||
### Agent wydajności testów
|
||||
|
||||
Przepływ pracy `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymaniowa Codex dla wolnych testów. Nie ma czystego harmonogramu: może go wyzwolić udane uruchomienie CI po wypchnięciu przez użytkownika innego niż bot do `main`, ale pomija się, jeśli tego dnia UTC inne wywołanie przez workflow-run już zostało uruchomione lub jest uruchomione. Ręczne wywołanie omija tę dzienną bramkę aktywności. Ścieżka buduje zgrupowany raport wydajności pełnego zestawu Vitest, pozwala Codex wprowadzać tylko niewielkie poprawki wydajności testów zachowujące pokrycie zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany, które zmniejszają bazową liczbę przechodzących testów. Jeśli baza ma testy kończące się niepowodzeniem, Codex może naprawiać tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie zatwierdzone. Gdy `main` przesunie się przed wylądowaniem wypchnięcia bota, ścieżka wykonuje rebase zweryfikowanej poprawki, ponownie uruchamia `pnpm check:changed` i ponawia wypchnięcie; konfliktujące nieaktualne poprawki są pomijane. Używa Ubuntu hostowanego przez GitHub, aby akcja Codex mogła zachować tę samą bezpieczną postawę bez sudo co agent dokumentacji.
|
||||
Workflow `Test Performance Agent` to sterowana zdarzeniami ścieżka utrzymania Codex dla wolnych testów. Nie ma czystego harmonogramu: udane uruchomienie CI dla wypchnięcia na `main` przez użytkownika innego niż bot może ją wyzwolić, ale jest pomijana, jeśli inne wywołanie workflow-run już działało lub działa danego dnia UTC. Ręczne wywołanie omija tę dzienną bramkę aktywności. Ścieżka buduje raport wydajności zgrupowanego pełnego zestawu Vitest, pozwala Codex wprowadzać tylko małe, zachowujące pokrycie poprawki wydajności testów zamiast szerokich refaktoryzacji, następnie ponownie uruchamia raport pełnego zestawu i odrzuca zmiany, które zmniejszają bazową liczbę przechodzących testów. Jeśli baza ma testy zakończone niepowodzeniem, Codex może naprawiać tylko oczywiste awarie, a raport pełnego zestawu po agencie musi przejść, zanim cokolwiek zostanie zatwierdzone. Gdy `main` posunie się naprzód, zanim wypchnięcie bota trafi do repozytorium, ścieżka wykonuje rebase zweryfikowanej poprawki, ponownie uruchamia `pnpm check:changed` i ponawia wypchnięcie; konfliktujące nieaktualne poprawki są pomijane. Używa GitHub-hosted Ubuntu, aby akcja Codex mogła zachować tę samą postawę bezpieczeństwa drop-sudo co agent dokumentacji.
|
||||
|
||||
### Zduplikowane PR po scaleniu
|
||||
|
||||
Przepływ pracy `Duplicate PRs After Merge` to ręczny przepływ pracy maintainerów do sprzątania duplikatów po wylądowaniu. Domyślnie działa w trybie dry-run i zamyka tylko jawnie wymienione PR, gdy `apply=true`. Przed mutacją GitHub weryfikuje, że wylądowany PR jest scalony oraz że każdy duplikat ma albo wspólny wskazywany problem, albo nakładające się zmienione fragmenty.
|
||||
Workflow `Duplicate PRs After Merge` to ręczny workflow utrzymaniowy dla osób utrzymujących, służący do sprzątania duplikatów po wylądowaniu zmian. Domyślnie działa jako dry-run i zamyka tylko jawnie wymienione PR, gdy `apply=true`. Przed modyfikacją GitHub weryfikuje, że PR, który wylądował, został scalony oraz że każdy duplikat ma albo wspólne przywołane zgłoszenie, albo nakładające się zmienione hunki.
|
||||
|
||||
```bash
|
||||
gh workflow run duplicate-after-merge.yml \
|
||||
@ -392,27 +392,27 @@ gh workflow run duplicate-after-merge.yml \
|
||||
-f apply=true
|
||||
```
|
||||
|
||||
## Lokalne bramki sprawdzania i trasowanie zmian
|
||||
## Lokalne bramki sprawdzania i routing zmian
|
||||
|
||||
Lokalna logika changed-lane znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka sprawdzania jest bardziej rygorystyczna wobec granic architektury niż szeroki zakres platformy CI:
|
||||
Logika lokalnych ścieżek zmian znajduje się w `scripts/changed-lanes.mjs` i jest wykonywana przez `scripts/check-changed.mjs`. Ta lokalna bramka sprawdzania jest surowsza wobec granic architektury niż szeroki zakres platformy CI:
|
||||
|
||||
- zmiany produkcyjne rdzenia uruchamiają typecheck produkcji rdzenia i testów rdzenia oraz lint/strażników rdzenia;
|
||||
- zmiany wyłącznie w testach rdzenia uruchamiają tylko typecheck testów rdzenia oraz lint rdzenia;
|
||||
- zmiany produkcyjne core uruchamiają typecheck produkcji core i testów core oraz lint/guardy core;
|
||||
- zmiany wyłącznie w testach core uruchamiają tylko typecheck testów core oraz lint core;
|
||||
- zmiany produkcyjne rozszerzeń uruchamiają typecheck produkcji rozszerzeń i testów rozszerzeń oraz lint rozszerzeń;
|
||||
- zmiany wyłącznie w testach rozszerzeń uruchamiają typecheck testów rozszerzeń oraz lint rozszerzeń;
|
||||
- zmiany publicznego SDK Plugin lub kontraktu Plugin rozszerzają się do typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów rdzenia (przemiatania rozszerzeń Vitest pozostają jawną pracą testową);
|
||||
- zmiany wersji obejmujące wyłącznie metadane wydań uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności katalogu głównego;
|
||||
- nieznane zmiany katalogu głównego/konfiguracji dla bezpieczeństwa przechodzą do wszystkich ścieżek sprawdzania.
|
||||
- publiczne zmiany SDK Plugin lub kontraktu Plugin rozszerzają zakres do typecheck rozszerzeń, ponieważ rozszerzenia zależą od tych kontraktów core (przebiegi rozszerzeń Vitest pozostają jawną pracą testową);
|
||||
- wersjonowania obejmujące tylko metadane wydania uruchamiają ukierunkowane sprawdzenia wersji/konfiguracji/zależności root;
|
||||
- nieznane zmiany root/konfiguracji przechodzą bezpiecznie na wszystkie ścieżki sprawdzania.
|
||||
|
||||
Lokalne trasowanie changed-test znajduje się w `scripts/test-projects.test-support.mjs` i jest celowo tańsze niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, a potem testy siostrzane i zależności z grafu importów. Współdzielona konfiguracja dostarczania do pokoju grupowego jest jednym z jawnych mapowań: zmiany konfiguracji odpowiedzi widocznych dla grupy, trybu dostarczania odpowiedzi źródłowych lub systemowego promptu narzędzia wiadomości przechodzą przez bazowe testy odpowiedzi oraz regresje dostarczania Discord i Slack, aby zmiana współdzielonej wartości domyślnej zakończyła się niepowodzeniem przed pierwszym wypchnięciem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana jest na tyle szeroka dla harnessu, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem.
|
||||
Lokalny routing zmienionych testów znajduje się w `scripts/test-projects.test-support.mjs` i celowo jest tańszy niż `check:changed`: bezpośrednie edycje testów uruchamiają same siebie, edycje źródeł preferują jawne mapowania, następnie testy siostrzane i zależności z grafu importów. Wspólna konfiguracja dostarczania group-room jest jednym z jawnych mapowań: zmiany w konfiguracji widocznych odpowiedzi grupowych, trybie dostarczania odpowiedzi źródłowych lub systemowym prompcie narzędzia wiadomości przechodzą przez główne testy odpowiedzi oraz regresje dostarczania Discord i Slack, aby wspólna zmiana domyślna zakończyła się niepowodzeniem przed pierwszym wypchnięciem PR. Używaj `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` tylko wtedy, gdy zmiana jest na tyle szeroka dla całego harnessu, że tani zmapowany zestaw nie jest wiarygodnym przybliżeniem.
|
||||
|
||||
## Walidacja Testbox
|
||||
|
||||
Uruchamiaj Testbox z katalogu głównego repozytorium i preferuj świeżo rozgrzany box dla szerokiego dowodu. Przed poświęceniem wolnej bramki na box, który został użyty ponownie, wygasł lub właśnie zgłosił nieoczekiwanie dużą synchronizację, uruchom najpierw `pnpm testbox:sanity` wewnątrz boxa.
|
||||
Uruchamiaj Testbox z katalogu głównego repozytorium i preferuj świeżo rozgrzane pudełko do szerokiego dowodu. Przed przeznaczeniem wolnej bramki na pudełko, które zostało ponownie użyte, wygasło albo właśnie zgłosiło nieoczekiwanie dużą synchronizację, najpierw uruchom `pnpm testbox:sanity` wewnątrz pudełka.
|
||||
|
||||
Sprawdzenie sanity szybko kończy się niepowodzeniem, gdy wymagane pliki katalogu głównego, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 śledzonych usunięć. Zwykle oznacza to, że zdalny stan synchronizacji nie jest wiarygodną kopią PR; zatrzymaj ten box i rozgrzej świeży zamiast debugować awarię testu produktu. Dla celowych PR z dużymi usunięciami ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego uruchomienia sanity.
|
||||
Sprawdzenie sanity szybko kończy się niepowodzeniem, gdy wymagane pliki root, takie jak `pnpm-lock.yaml`, zniknęły albo gdy `git status --short` pokazuje co najmniej 200 śledzonych usunięć. Zwykle oznacza to, że zdalny stan synchronizacji nie jest wiarygodną kopią PR; zatrzymaj to pudełko i rozgrzej świeże zamiast debugować awarię testu produktu. Dla celowych PR z dużą liczbą usunięć ustaw `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` dla tego przebiegu sanity.
|
||||
|
||||
`pnpm testbox:run` kończy również lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez wyjścia po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę osłonę, albo użyj większej wartości w milisekundach dla nietypowo dużych lokalnych różnic.
|
||||
`pnpm testbox:run` kończy także lokalne wywołanie Blacksmith CLI, które pozostaje w fazie synchronizacji przez ponad pięć minut bez danych wyjściowych po synchronizacji. Ustaw `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, aby wyłączyć tę osłonę, albo użyj większej wartości w milisekundach dla wyjątkowo dużych lokalnych różnic.
|
||||
|
||||
## Powiązane
|
||||
|
||||
|
||||
@ -1,184 +1,185 @@
|
||||
---
|
||||
read_when:
|
||||
- Potrzebujesz dokładnego omówienia krok po kroku pętli agenta lub zdarzeń cyklu życia
|
||||
- Zmieniasz kolejkowanie sesji, zapisy transkryptu albo zachowanie blokady zapisu sesji
|
||||
- Potrzebujesz dokładnego przewodnika po pętli agenta lub zdarzeniach cyklu życia
|
||||
- Zmieniasz kolejkowanie sesji, zapisywanie transkrypcji lub działanie blokady zapisu sesji
|
||||
summary: Cykl życia pętli agenta, strumienie i semantyka oczekiwania
|
||||
title: Pętla agenta
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T09:46:17Z"
|
||||
generated_at: "2026-04-30T18:39:00Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32
|
||||
source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df
|
||||
source_path: concepts/agent-loop.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Pętla agentowa to pełne „rzeczywiste” uruchomienie agenta: przyjęcie danych wejściowych → złożenie kontekstu → inferencja modelu →
|
||||
Pętla agentowa to pełny „rzeczywisty” przebieg agenta: przyjęcie danych wejściowych → złożenie kontekstu → inferencja modelu →
|
||||
wykonanie narzędzi → strumieniowanie odpowiedzi → utrwalenie. To autorytatywna ścieżka, która zamienia wiadomość
|
||||
w działania i końcową odpowiedź, jednocześnie utrzymując spójny stan sesji.
|
||||
w działania i końcową odpowiedź, utrzymując spójny stan sesji.
|
||||
|
||||
W OpenClaw pętla to pojedyncze, serializowane uruchomienie na sesję, które emituje zdarzenia cyklu życia i strumienia,
|
||||
gdy model myśli, wywołuje narzędzia i strumieniuje dane wyjściowe. Ten dokument wyjaśnia, jak ta autentyczna pętla jest
|
||||
połączona od końca do końca.
|
||||
W OpenClaw pętla jest pojedynczym, serializowanym przebiegiem na sesję, który emituje zdarzenia cyklu życia i strumienia,
|
||||
gdy model rozumuje, wywołuje narzędzia i strumieniuje wynik. Ten dokument wyjaśnia, jak ta autentyczna pętla jest
|
||||
połączona od początku do końca.
|
||||
|
||||
## Punkty wejścia
|
||||
|
||||
- RPC Gateway: `agent` i `agent.wait`.
|
||||
- Gateway RPC: `agent` i `agent.wait`.
|
||||
- CLI: polecenie `agent`.
|
||||
|
||||
## Jak to działa (wysoki poziom)
|
||||
## Jak to działa (ogólnie)
|
||||
|
||||
1. RPC `agent` waliduje parametry, rozwiązuje sesję (sessionKey/sessionId), utrwala metadane sesji i natychmiast zwraca `{ runId, acceptedAt }`.
|
||||
1. RPC `agent` weryfikuje parametry, rozwiązuje sesję (`sessionKey`/`sessionId`), utrwala metadane sesji i natychmiast zwraca `{ runId, acceptedAt }`.
|
||||
2. `agentCommand` uruchamia agenta:
|
||||
- rozwiązuje model oraz domyślne ustawienia myślenia/verbose/trace
|
||||
- wczytuje migawkę Skills
|
||||
- wywołuje `runEmbeddedPiAgent` (środowisko uruchomieniowe pi-agent-core)
|
||||
- emituje **koniec/błąd cyklu życia**, jeśli osadzona pętla go nie wyemituje
|
||||
- rozwiązuje model oraz domyślne wartości myślenia/szczegółowości/śledzenia
|
||||
- ładuje migawkę Skills
|
||||
- wywołuje `runEmbeddedPiAgent` (środowisko uruchomieniowe `pi-agent-core`)
|
||||
- emituje **zakończenie/błąd cyklu życia**, jeśli osadzona pętla tego nie zrobi
|
||||
3. `runEmbeddedPiAgent`:
|
||||
- serializuje uruchomienia przez kolejki na sesję i globalne
|
||||
- rozwiązuje model oraz profil uwierzytelniania i buduje sesję Pi
|
||||
- subskrybuje zdarzenia Pi i strumieniuje delty asystenta/narzędzi
|
||||
- wymusza limit czasu -> przerywa uruchomienie po jego przekroczeniu
|
||||
- zwraca payloady oraz metadane użycia
|
||||
4. `subscribeEmbeddedPiSession` łączy zdarzenia pi-agent-core ze strumieniem `agent` OpenClaw:
|
||||
- serializuje przebiegi przez kolejki na sesję i kolejki globalne
|
||||
- rozwiązuje model oraz profil uwierzytelniania i buduje sesję pi
|
||||
- subskrybuje zdarzenia pi i strumieniuje delty asystenta/narzędzi
|
||||
- wymusza limit czasu -> przerywa przebieg po jego przekroczeniu
|
||||
- dla tur serwera aplikacji Codex przerywa zaakceptowaną turę, która przestaje generować postęp serwera aplikacji przed zdarzeniem końcowym
|
||||
- zwraca ładunki i metadane użycia
|
||||
4. `subscribeEmbeddedPiSession` łączy zdarzenia `pi-agent-core` ze strumieniem `agent` OpenClaw:
|
||||
- zdarzenia narzędzi => `stream: "tool"`
|
||||
- delty asystenta => `stream: "assistant"`
|
||||
- zdarzenia cyklu życia => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`)
|
||||
5. `agent.wait` używa `waitForAgentRun`:
|
||||
- czeka na **koniec/błąd cyklu życia** dla `runId`
|
||||
- czeka na **zakończenie/błąd cyklu życia** dla `runId`
|
||||
- zwraca `{ status: ok|error|timeout, startedAt, endedAt, error? }`
|
||||
|
||||
## Kolejkowanie + współbieżność
|
||||
## Kolejkowanie i współbieżność
|
||||
|
||||
- Uruchomienia są serializowane według klucza sesji (pas sesji) i opcjonalnie przez pas globalny.
|
||||
- Przebiegi są serializowane według klucza sesji (ścieżka sesji) i opcjonalnie przez ścieżkę globalną.
|
||||
- Zapobiega to wyścigom narzędzi/sesji i utrzymuje spójną historię sesji.
|
||||
- Kanały komunikacji mogą wybierać tryby kolejek (collect/steer/followup), które zasilają ten system pasów.
|
||||
- Kanały komunikacji mogą wybierać tryby kolejkowania (zbieranie/sterowanie/kontynuacja), które zasilają ten system ścieżek.
|
||||
Zobacz [Kolejka poleceń](/pl/concepts/queue).
|
||||
- Zapisy transkrypcji są także chronione przez blokadę zapisu sesji na pliku sesji. Blokada jest
|
||||
świadoma procesu i oparta na pliku, więc wychwytuje zapisujących, którzy omijają kolejkę w procesie lub pochodzą
|
||||
- Zapisy transkrypcji są także chronione blokadą zapisu sesji na pliku sesji. Blokada jest
|
||||
świadoma procesów i oparta na plikach, więc wychwytuje zapisujących, którzy omijają kolejkę w procesie albo pochodzą
|
||||
z innego procesu.
|
||||
- Blokady zapisu sesji domyślnie nie są reentrantne. Jeśli helper celowo zagnieżdża pozyskanie
|
||||
tej samej blokady, zachowując jednego logicznego zapisującego, musi jawnie się na to zdecydować przez
|
||||
- Blokady zapisu sesji domyślnie nie są reentrantne. Jeśli pomocnik celowo zagnieżdża pozyskanie
|
||||
tej samej blokady, zachowując jednego logicznego zapisującego, musi jawnie się na to zdecydować za pomocą
|
||||
`allowReentrant: true`.
|
||||
|
||||
## Przygotowanie sesji + obszaru roboczego
|
||||
## Przygotowanie sesji i przestrzeni roboczej
|
||||
|
||||
- Obszar roboczy jest rozwiązywany i tworzony; uruchomienia w piaskownicy mogą przekierować do katalogu głównego obszaru roboczego piaskownicy.
|
||||
- Skills są wczytywane (lub ponownie używane z migawki) i wstrzykiwane do env oraz promptu.
|
||||
- Pliki bootstrap/kontekstowe są rozwiązywane i wstrzykiwane do raportu promptu systemowego.
|
||||
- Przestrzeń robocza jest rozwiązywana i tworzona; przebiegi w piaskownicy mogą przekierować do katalogu głównego przestrzeni roboczej piaskownicy.
|
||||
- Skills są ładowane (albo ponownie używane z migawki) i wstrzykiwane do środowiska oraz promptu.
|
||||
- Pliki rozruchowe/kontekstowe są rozwiązywane i wstrzykiwane do raportu promptu systemowego.
|
||||
- Pozyskiwana jest blokada zapisu sesji; `SessionManager` jest otwierany i przygotowywany przed strumieniowaniem. Każda
|
||||
późniejsza ścieżka przepisywania transkrypcji, Compaction lub obcinania musi uzyskać tę samą blokadę przed otwarciem lub
|
||||
późniejsza ścieżka przepisywania, Compaction albo skracania transkrypcji musi pozyskać tę samą blokadę przed otwarciem albo
|
||||
modyfikacją pliku transkrypcji.
|
||||
|
||||
## Składanie promptu + prompt systemowy
|
||||
## Składanie promptu i prompt systemowy
|
||||
|
||||
- Prompt systemowy jest budowany z bazowego promptu OpenClaw, promptu Skills, kontekstu bootstrap i nadpisań na uruchomienie.
|
||||
- Limity specyficzne dla modelu i tokeny rezerwowe Compaction są wymuszane.
|
||||
- Prompt systemowy jest budowany z bazowego promptu OpenClaw, promptu Skills, kontekstu rozruchowego i nadpisań dla danego przebiegu.
|
||||
- Wymuszane są limity specyficzne dla modelu oraz tokeny rezerwy Compaction.
|
||||
- Zobacz [Prompt systemowy](/pl/concepts/system-prompt), aby sprawdzić, co widzi model.
|
||||
|
||||
## Punkty hooków (gdzie możesz przechwytywać)
|
||||
## Punkty zaczepienia (gdzie można przechwycić)
|
||||
|
||||
OpenClaw ma dwa systemy hooków:
|
||||
|
||||
- **Hooki wewnętrzne** (hooki Gateway): skrypty sterowane zdarzeniami dla poleceń i zdarzeń cyklu życia.
|
||||
- **Hooki Plugin**: punkty rozszerzeń wewnątrz cyklu życia agenta/narzędzia i potoku Gateway.
|
||||
- **Hooki Plugin**: punkty rozszerzeń wewnątrz cyklu życia agenta/narzędzia i potoku gateway.
|
||||
|
||||
### Hooki wewnętrzne (hooki Gateway)
|
||||
|
||||
- **`agent:bootstrap`**: działa podczas budowania plików bootstrap, zanim prompt systemowy zostanie sfinalizowany.
|
||||
Użyj tego, aby dodać/usunąć pliki kontekstu bootstrap.
|
||||
- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokument o Hookach).
|
||||
- **`agent:bootstrap`**: działa podczas budowania plików rozruchowych, zanim prompt systemowy zostanie sfinalizowany.
|
||||
Użyj tego, aby dodać/usunąć pliki kontekstu rozruchowego.
|
||||
- **Hooki poleceń**: `/new`, `/reset`, `/stop` i inne zdarzenia poleceń (zobacz dokumentację hooków).
|
||||
|
||||
Zobacz [Hooki](/pl/automation/hooks), aby poznać konfigurację i przykłady.
|
||||
|
||||
### Hooki Plugin (cykl życia agenta + Gateway)
|
||||
### Hooki Plugin (cykl życia agenta i gateway)
|
||||
|
||||
Działają wewnątrz pętli agenta lub potoku Gateway:
|
||||
Działają wewnątrz pętli agenta albo potoku gateway:
|
||||
|
||||
- **`before_model_resolve`**: działa przed sesją (bez `messages`), aby deterministycznie nadpisać dostawcę/model przed rozwiązaniem modelu.
|
||||
- **`before_prompt_build`**: działa po wczytaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` lub `appendSystemContext` przed wysłaniem promptu. Użyj `prependContext` dla dynamicznego tekstu na turę, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znajdować się w przestrzeni promptu systemowego.
|
||||
- **`before_agent_start`**: starszy hook kompatybilności, który może działać w dowolnej fazie; preferuj jawne hooki powyżej.
|
||||
- **`before_agent_reply`**: działa po działaniach inline i przed wywołaniem LLM, pozwalając Plugin przejąć turę i zwrócić syntetyczną odpowiedź albo całkowicie wyciszyć turę.
|
||||
- **`agent_end`**: sprawdza końcową listę wiadomości i metadane uruchomienia po zakończeniu.
|
||||
- **`before_compaction` / `after_compaction`**: obserwuje lub adnotuje cykle Compaction.
|
||||
- **`before_prompt_build`**: działa po załadowaniu sesji (z `messages`), aby wstrzyknąć `prependContext`, `systemPrompt`, `prependSystemContext` albo `appendSystemContext` przed wysłaniem promptu. Użyj `prependContext` dla dynamicznego tekstu na turę, a pól kontekstu systemowego dla stabilnych wskazówek, które powinny znaleźć się w przestrzeni promptu systemowego.
|
||||
- **`before_agent_start`**: starszy hook zgodności, który może działać w obu fazach; preferuj jawne hooki powyżej.
|
||||
- **`before_agent_reply`**: działa po akcjach wbudowanych i przed wywołaniem LLM, pozwalając Plugin przejąć turę i zwrócić syntetyczną odpowiedź albo całkowicie wyciszyć turę.
|
||||
- **`agent_end`**: sprawdza końcową listę wiadomości i metadane przebiegu po zakończeniu.
|
||||
- **`before_compaction` / `after_compaction`**: obserwuje albo adnotuje cykle Compaction.
|
||||
- **`before_tool_call` / `after_tool_call`**: przechwytuje parametry/wyniki narzędzi.
|
||||
- **`before_install`**: sprawdza wbudowane wyniki skanowania i opcjonalnie blokuje instalacje Skills lub Plugin.
|
||||
- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi, zanim zostaną zapisane w transkrypcji sesji należącej do OpenClaw.
|
||||
- **`before_install`**: sprawdza wbudowane wyniki skanowania i opcjonalnie blokuje instalacje Skills albo Plugin.
|
||||
- **`tool_result_persist`**: synchronicznie przekształca wyniki narzędzi przed zapisaniem ich do transkrypcji sesji należącej do OpenClaw.
|
||||
- **`message_received` / `message_sending` / `message_sent`**: hooki wiadomości przychodzących i wychodzących.
|
||||
- **`session_start` / `session_end`**: granice cyklu życia sesji.
|
||||
- **`gateway_start` / `gateway_stop`**: zdarzenia cyklu życia Gateway.
|
||||
- **`gateway_start` / `gateway_stop`**: zdarzenia cyklu życia gateway.
|
||||
|
||||
Reguły decyzyjne hooków dla strażników wychodzących/narzędzi:
|
||||
Reguły decyzji hooków dla zabezpieczeń wychodzących/narzędzi:
|
||||
|
||||
- `before_tool_call`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_tool_call`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady.
|
||||
- `before_tool_call`: `{ block: false }` jest operacją bez efektu i nie usuwa wcześniejszej blokady.
|
||||
- `before_install`: `{ block: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `before_install`: `{ block: false }` nic nie robi i nie usuwa wcześniejszej blokady.
|
||||
- `before_install`: `{ block: false }` jest operacją bez efektu i nie usuwa wcześniejszej blokady.
|
||||
- `message_sending`: `{ cancel: true }` jest końcowe i zatrzymuje handlery o niższym priorytecie.
|
||||
- `message_sending`: `{ cancel: false }` nic nie robi i nie usuwa wcześniejszego anulowania.
|
||||
- `message_sending`: `{ cancel: false }` jest operacją bez efektu i nie usuwa wcześniejszego anulowania.
|
||||
|
||||
Zobacz [Hooki Plugin](/pl/plugins/hooks), aby poznać API hooków i szczegóły rejestracji.
|
||||
|
||||
Harnessy mogą różnie adaptować te hooki. Harness serwera aplikacji Codex zachowuje
|
||||
hooki Plugin OpenClaw jako kontrakt kompatybilności dla udokumentowanych powierzchni lustrzanych,
|
||||
podczas gdy natywne hooki Codex pozostają oddzielnym, niższopoziomowym mechanizmem Codex.
|
||||
Uprzęże mogą dostosowywać te hooki inaczej. Uprząż serwera aplikacji Codex zachowuje
|
||||
hooki Plugin OpenClaw jako kontrakt zgodności dla udokumentowanych powierzchni lustrzanych,
|
||||
podczas gdy natywne hooki Codex pozostają osobnym mechanizmem Codex niższego poziomu.
|
||||
|
||||
## Strumieniowanie + częściowe odpowiedzi
|
||||
## Strumieniowanie i częściowe odpowiedzi
|
||||
|
||||
- Delty asystenta są strumieniowane z pi-agent-core i emitowane jako zdarzenia `assistant`.
|
||||
- Strumieniowanie bloków może emitować częściowe odpowiedzi na `text_end` albo `message_end`.
|
||||
- Strumieniowanie rozumowania może być emitowane jako oddzielny strumień albo jako odpowiedzi blokowe.
|
||||
- Zobacz [Strumieniowanie](/pl/concepts/streaming), aby poznać zachowanie fragmentowania i odpowiedzi blokowych.
|
||||
- Delty asystenta są strumieniowane z `pi-agent-core` i emitowane jako zdarzenia `assistant`.
|
||||
- Strumieniowanie blokowe może emitować częściowe odpowiedzi przy `text_end` albo `message_end`.
|
||||
- Strumieniowanie rozumowania może być emitowane jako osobny strumień albo jako odpowiedzi blokowe.
|
||||
- Zobacz [Strumieniowanie](/pl/concepts/streaming), aby poznać dzielenie na fragmenty i zachowanie odpowiedzi blokowych.
|
||||
|
||||
## Wykonywanie narzędzi + narzędzia komunikacji
|
||||
## Wykonywanie narzędzi i narzędzia wiadomości
|
||||
|
||||
- Zdarzenia start/update/end narzędzi są emitowane w strumieniu `tool`.
|
||||
- Wyniki narzędzi są oczyszczane pod kątem rozmiaru i payloadów obrazów przed logowaniem/emitowaniem.
|
||||
- Wysyłki narzędzi komunikacji są śledzone, aby tłumić zduplikowane potwierdzenia asystenta.
|
||||
- Zdarzenia rozpoczęcia/aktualizacji/zakończenia narzędzia są emitowane w strumieniu `tool`.
|
||||
- Wyniki narzędzi są oczyszczane pod kątem rozmiaru i ładunków obrazów przed logowaniem/emitowaniem.
|
||||
- Wysłania narzędzi wiadomości są śledzone, aby tłumić zduplikowane potwierdzenia asystenta.
|
||||
|
||||
## Kształtowanie odpowiedzi + tłumienie
|
||||
## Kształtowanie i tłumienie odpowiedzi
|
||||
|
||||
- Końcowe payloady są składane z:
|
||||
- Końcowe ładunki są składane z:
|
||||
- tekstu asystenta (i opcjonalnego rozumowania)
|
||||
- podsumowań narzędzi inline (gdy verbose + dozwolone)
|
||||
- tekstu błędu asystenta, gdy model zgłasza błąd
|
||||
- wbudowanych podsumowań narzędzi (gdy szczegółowość jest włączona i dozwolona)
|
||||
- tekstu błędu asystenta, gdy model zwraca błąd
|
||||
- Dokładny cichy token `NO_REPLY` / `no_reply` jest filtrowany z wychodzących
|
||||
payloadów.
|
||||
- Duplikaty narzędzi komunikacji są usuwane z końcowej listy payloadów.
|
||||
- Jeśli nie pozostaną żadne renderowalne payloady, a narzędzie zwróciło błąd, emitowana jest zastępcza odpowiedź błędu narzędzia
|
||||
(chyba że narzędzie komunikacji już wysłało widoczną dla użytkownika odpowiedź).
|
||||
ładunków.
|
||||
- Duplikaty narzędzi wiadomości są usuwane z końcowej listy ładunków.
|
||||
- Jeśli nie pozostaną żadne renderowalne ładunki, a narzędzie zwróciło błąd, emitowana jest zastępcza odpowiedź błędu narzędzia
|
||||
(chyba że narzędzie wiadomości już wysłało odpowiedź widoczną dla użytkownika).
|
||||
|
||||
## Compaction + ponowne próby
|
||||
## Compaction i ponowne próby
|
||||
|
||||
- Auto-Compaction emituje zdarzenia strumienia `compaction` i może wywołać ponowną próbę.
|
||||
- Przy ponownej próbie bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanych danych wyjściowych.
|
||||
- Automatyczna Compaction emituje zdarzenia strumienia `compaction` i może wywołać ponowną próbę.
|
||||
- Przy ponownej próbie bufory w pamięci i podsumowania narzędzi są resetowane, aby uniknąć zduplikowanego wyniku.
|
||||
- Zobacz [Compaction](/pl/concepts/compaction), aby poznać potok Compaction.
|
||||
|
||||
## Strumienie zdarzeń (obecnie)
|
||||
|
||||
- `lifecycle`: emitowany przez `subscribeEmbeddedPiSession` (i awaryjnie przez `agentCommand`)
|
||||
- `assistant`: strumieniowane delty z pi-agent-core
|
||||
- `tool`: strumieniowane zdarzenia narzędzi z pi-agent-core
|
||||
- `lifecycle`: emitowany przez `subscribeEmbeddedPiSession` (oraz awaryjnie przez `agentCommand`)
|
||||
- `assistant`: strumieniowane delty z `pi-agent-core`
|
||||
- `tool`: strumieniowane zdarzenia narzędzi z `pi-agent-core`
|
||||
|
||||
## Obsługa kanału czatu
|
||||
## Obsługa kanałów czatu
|
||||
|
||||
- Delty asystenta są buforowane w wiadomościach czatu `delta`.
|
||||
- Chat `final` jest emitowany przy **końcu/błędzie cyklu życia**.
|
||||
- `final` czatu jest emitowane przy **zakończeniu/błędzie cyklu życia**.
|
||||
|
||||
## Limity czasu
|
||||
|
||||
- Domyślnie `agent.wait`: 30 s (tylko oczekiwanie). Parametr `timeoutMs` nadpisuje tę wartość.
|
||||
- Środowisko uruchomieniowe agenta: domyślne `agents.defaults.timeoutSeconds` to 172800 s (48 godzin); wymuszane przez timer przerwania w `runEmbeddedPiAgent`.
|
||||
- Środowisko uruchomieniowe Cron: izolowane `timeoutSeconds` tury agenta należy do cron. Harmonogram uruchamia ten timer, gdy wykonanie się zaczyna, przerywa bazowe uruchomienie w skonfigurowanym terminie, a następnie wykonuje ograniczone sprzątanie przed zapisaniem limitu czasu, aby nieaktualna sesja potomna nie mogła zablokować pasa.
|
||||
- Odzyskiwanie zablokowanej sesji: przy włączonej diagnostyce `diagnostics.stuckSessionWarnMs` wykrywa długie sesje `processing`. Aktywne osadzone uruchomienia, aktywne operacje odpowiedzi i aktywne zadania pasa sesji domyślnie pozostają tylko ostrzeżeniami; jeśli diagnostyka nie pokazuje aktywnej pracy dla sesji, watchdog zwalnia dotknięty pas sesji, aby zakolejkowana praca startowa mogła się opróżnić.
|
||||
- Limit bezczynności modelu: OpenClaw przerywa żądanie modelu, gdy przed upływem okna bezczynności nie przyjdą żadne fragmenty odpowiedzi. `models.providers.<id>.timeoutSeconds` wydłuża ten watchdog bezczynności dla wolnych lokalnych/samodzielnie hostowanych dostawców; w przeciwnym razie OpenClaw używa `agents.defaults.timeoutSeconds`, gdy jest skonfigurowane, domyślnie z limitem 120 s. Uruchomienia wyzwalane przez Cron bez jawnego limitu czasu modelu lub agenta wyłączają watchdog bezczynności i polegają na zewnętrznym limicie czasu cron.
|
||||
- Limit czasu żądania HTTP dostawcy: `models.providers.<id>.timeoutSeconds` stosuje się do pobrań HTTP modelu tego dostawcy, w tym połączenia, nagłówków, treści, limitu czasu żądania SDK, całkowitej obsługi przerwania chronionego fetch oraz watchdog bezczynności strumienia modelu. Używaj tego dla wolnych lokalnych/samodzielnie hostowanych dostawców, takich jak Ollama, zanim zwiększysz limit czasu całego środowiska uruchomieniowego agenta.
|
||||
- Domyślne `agent.wait`: 30 s (tylko oczekiwanie). Parametr `timeoutMs` nadpisuje tę wartość.
|
||||
- Środowisko uruchomieniowe agenta: domyślne `agents.defaults.timeoutSeconds` wynosi 172800 s (48 godzin); wymuszane w timerze przerwania `runEmbeddedPiAgent`.
|
||||
- Środowisko uruchomieniowe Cron: izolowany `timeoutSeconds` tury agenta jest własnością cron. Harmonogram uruchamia ten timer, gdy rozpoczyna się wykonanie, przerywa bazowy przebieg przy skonfigurowanym terminie, a następnie uruchamia ograniczone sprzątanie przed zapisaniem limitu czasu, aby przestarzała sesja podrzędna nie mogła zablokować ścieżki.
|
||||
- Odzyskiwanie zablokowanej sesji: przy włączonej diagnostyce `diagnostics.stuckSessionWarnMs` wykrywa długo trwające sesje `processing`. Aktywne osadzone przebiegi, aktywne operacje odpowiedzi i aktywne zadania ścieżki sesji domyślnie pozostają tylko ostrzeżeniami; jeśli diagnostyka nie pokazuje aktywnej pracy dla sesji, watchdog zwalnia dotkniętą ścieżkę sesji, aby zakolejkowana praca startowa mogła się opróżnić.
|
||||
- Limit bezczynności modelu: OpenClaw przerywa żądanie modelu, gdy przed upływem okna bezczynności nie nadejdą żadne fragmenty odpowiedzi. `models.providers.<id>.timeoutSeconds` wydłuża ten watchdog bezczynności dla wolnych lokalnych/samohostowanych dostawców; w przeciwnym razie OpenClaw używa `agents.defaults.timeoutSeconds`, gdy jest skonfigurowane, domyślnie ograniczone do 120 s. Przebiegi wyzwalane przez Cron bez jawnego limitu czasu modelu lub agenta wyłączają watchdog bezczynności i polegają na zewnętrznym limicie czasu cron.
|
||||
- Limit czasu żądania HTTP dostawcy: `models.providers.<id>.timeoutSeconds` dotyczy żądań HTTP fetch modelu tego dostawcy, w tym połączenia, nagłówków, treści, limitu czasu żądania SDK, całkowitej obsługi przerwania chronionego fetch oraz watchdoga bezczynności strumienia modelu. Użyj tego dla wolnych lokalnych/samohostowanych dostawców, takich jak Ollama, zanim zwiększysz limit czasu całego środowiska uruchomieniowego agenta.
|
||||
|
||||
## Gdzie rzeczy mogą zakończyć się wcześniej
|
||||
|
||||
- Limit czasu agenta (przerwanie)
|
||||
- AbortSignal (anulowanie)
|
||||
- Rozłączenie Gateway lub limit czasu RPC
|
||||
- Rozłączenie Gateway albo limit czasu RPC
|
||||
- Limit czasu `agent.wait` (tylko oczekiwanie, nie zatrzymuje agenta)
|
||||
|
||||
## Powiązane
|
||||
|
||||
@ -5,28 +5,28 @@ read_when:
|
||||
summary: Tryby kolejki automatycznych odpowiedzi, wartości domyślne i nadpisania dla poszczególnych sesji
|
||||
title: Kolejka poleceń
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T09:49:53Z"
|
||||
generated_at: "2026-04-30T18:39:00Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d
|
||||
source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0
|
||||
source_path: concepts/queue.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Serializujemy przychodzące uruchomienia automatycznych odpowiedzi (wszystkie kanały) przez małą kolejkę w procesie, aby zapobiec kolizjom wielu uruchomień agenta, jednocześnie nadal pozwalając na bezpiełą równoległość między sesjami.
|
||||
Serializujemy przychodzące uruchomienia automatycznych odpowiedzi (wszystkie kanały) przez niewielką kolejkę w procesie, aby zapobiec kolizjom między wieloma uruchomieniami agenta, jednocześnie nadal pozwalając na bezpieczną równoległość między sesjami.
|
||||
|
||||
## Dlaczego
|
||||
|
||||
- Uruchomienia automatycznych odpowiedzi mogą być kosztowne (wywołania LLM) i mogą kolidować, gdy wiele przychodzących wiadomości pojawia się blisko siebie.
|
||||
- Serializacja pozwala uniknąć rywalizacji o współdzielone zasoby (pliki sesji, logi, stdin CLI) i zmniejsza ryzyko limitów szybkości po stronie dostawcy.
|
||||
- Uruchomienia automatycznych odpowiedzi mogą być kosztowne (wywołania LLM) i mogą kolidować, gdy wiele wiadomości przychodzących nadejdzie w krótkim odstępie czasu.
|
||||
- Serializacja pozwala uniknąć rywalizacji o współdzielone zasoby (pliki sesji, dzienniki, stdin CLI) i zmniejsza ryzyko limitów szybkości po stronie upstream.
|
||||
|
||||
## Jak to działa
|
||||
|
||||
- Kolejka FIFO świadoma pasów opróżnia każdy pas z konfigurowalnym limitem współbieżności (domyślnie 1 dla nieskonfigurowanych pasów; main domyślnie 4, subagent 8).
|
||||
- `runEmbeddedPiAgent` dodaje zadania do kolejki według **klucza sesji** (pas `session:<key>`), aby zagwarantować tylko jedno aktywne uruchomienie na sesję.
|
||||
- Każde uruchomienie sesji jest następnie dodawane do **globalnego pasa** (domyślnie `main`), więc ogólna równoległość jest ograniczona przez `agents.defaults.maxConcurrent`.
|
||||
- Gdy włączone jest szczegółowe logowanie, uruchomienia w kolejce emitują krótkie powiadomienie, jeśli czekały ponad około 2 s przed startem.
|
||||
- Wskaźniki pisania nadal uruchamiają się natychmiast po dodaniu do kolejki (gdy kanał to obsługuje), więc doświadczenie użytkownika pozostaje bez zmian, gdy czekamy na swoją kolej.
|
||||
- Kolejka FIFO świadoma torów opróżnia każdy tor z konfigurowalnym limitem współbieżności (domyślnie 1 dla nieskonfigurowanych torów; główny domyślnie 4, subagent 8).
|
||||
- `runEmbeddedPiAgent` dodaje zadania do kolejki według **klucza sesji** (tor `session:<key>`), aby zagwarantować tylko jedno aktywne uruchomienie na sesję.
|
||||
- Każde uruchomienie sesji jest następnie kolejkowane do **globalnego toru** (domyślnie `main`), więc ogólna równoległość jest ograniczana przez `agents.defaults.maxConcurrent`.
|
||||
- Gdy włączone jest szczegółowe logowanie, zakolejkowane uruchomienia emitują krótkie powiadomienie, jeśli czekały ponad ~2 s przed startem.
|
||||
- Wskaźniki pisania nadal uruchamiają się natychmiast po dodaniu do kolejki (gdy kanał to obsługuje), więc doświadczenie użytkownika pozostaje niezmienione podczas oczekiwania na swoją kolej.
|
||||
|
||||
## Domyślne wartości
|
||||
|
||||
@ -37,30 +37,30 @@ Gdy nie ustawiono inaczej, wszystkie powierzchnie kanałów przychodzących uży
|
||||
- `cap: 20`
|
||||
- `drop: "summarize"`
|
||||
|
||||
`steer` jest domyślne, ponieważ utrzymuje aktywną turę modelu responsywną bez
|
||||
uruchamiania drugiego przebiegu sesji. Opróżnia wszystkie wiadomości sterujące,
|
||||
które dotarły przed następną granicą modelu. Jeśli bieżące uruchomienie nie może
|
||||
przyjąć sterowania, OpenClaw wraca do wpisu kolejki follow-up.
|
||||
`steer` jest ustawieniem domyślnym, ponieważ utrzymuje aktywną turę modelu responsywną bez
|
||||
uruchamiania drugiego przebiegu sesji. Opróżnia wszystkie wiadomości sterujące, które dotarły
|
||||
przed następną granicą modelu. Jeśli bieżące uruchomienie nie może przyjąć sterowania,
|
||||
OpenClaw przechodzi awaryjnie do wpisu kolejki followup.
|
||||
|
||||
## Tryby kolejki
|
||||
|
||||
Wiadomości przychodzące mogą sterować bieżącym uruchomieniem, czekać na turę follow-up albo robić jedno i drugie:
|
||||
Wiadomości przychodzące mogą sterować bieżącym uruchomieniem, czekać na turę followup albo robić jedno i drugie:
|
||||
|
||||
- `steer`: dodaje wiadomości sterujące do aktywnego środowiska uruchomieniowego. Pi dostarcza wszystkie oczekujące wiadomości sterujące **po zakończeniu wykonywania wywołań narzędzi przez bieżącą turę asystenta**, przed następnym wywołaniem LLM; serwer aplikacji Codex otrzymuje jedno zbiorcze `turn/steer`. Jeśli uruchomienie nie przesyła aktywnie strumienia lub sterowanie jest niedostępne, OpenClaw wraca do wpisu kolejki follow-up.
|
||||
- `queue` (starszy tryb): dawne sterowanie pojedynczo. Pi dostarcza jedną wiadomość sterującą z kolejki na każdej granicy modelu; serwer aplikacji Codex otrzymuje osobne żądania `turn/steer`. Preferuj `steer`, chyba że potrzebujesz poprzedniego serializowanego zachowania.
|
||||
- `steer`: kolejkuje wiadomości sterujące do aktywnego środowiska wykonawczego. Pi dostarcza wszystkie oczekujące wiadomości sterujące **po zakończeniu wykonywania wywołań narzędzi przez bieżącą turę asystenta**, przed następnym wywołaniem LLM; serwer aplikacji Codex otrzymuje jedno zbiorcze `turn/steer`. Jeśli uruchomienie nie prowadzi aktywnie streamingu albo sterowanie jest niedostępne, OpenClaw przechodzi awaryjnie do wpisu kolejki followup.
|
||||
- `queue` (starsze): stare sterowanie po jednej wiadomości naraz. Pi dostarcza jedną zakolejkowaną wiadomość sterującą przy każdej granicy modelu; serwer aplikacji Codex otrzymuje osobne żądania `turn/steer`. Preferuj `steer`, chyba że potrzebujesz poprzedniego serializowanego zachowania.
|
||||
- `followup`: dodaje każdą wiadomość do kolejki na późniejszą turę agenta po zakończeniu bieżącego uruchomienia.
|
||||
- `collect`: scala wiadomości z kolejki w **pojedynczą** turę follow-up po okresie ciszy. Jeśli wiadomości kierują do różnych kanałów/wątków, są opróżniane osobno, aby zachować trasowanie.
|
||||
- `steer-backlog` (czyli `steer+backlog`): steruje teraz **i** zachowuje tę samą wiadomość na turę follow-up.
|
||||
- `interrupt` (starszy tryb): przerywa aktywne uruchomienie dla tej sesji, a następnie uruchamia najnowszą wiadomość.
|
||||
- `collect`: scala zakolejkowane wiadomości w **pojedynczą** turę followup po oknie ciszy. Jeśli wiadomości są kierowane do różnych kanałów/wątków, są opróżniane pojedynczo, aby zachować routing.
|
||||
- `steer-backlog` (alias `steer+backlog`): steruje teraz **i** zachowuje tę samą wiadomość na turę followup.
|
||||
- `interrupt` (starsze): przerywa aktywne uruchomienie dla tej sesji, a następnie uruchamia najnowszą wiadomość.
|
||||
|
||||
Steer-backlog oznacza, że możesz otrzymać odpowiedź follow-up po sterowanym
|
||||
uruchomieniu, więc powierzchnie strumieniowe mogą wyglądać jak duplikaty.
|
||||
Preferuj `collect`/`steer`, jeśli chcesz jedną odpowiedź na wiadomość przychodzącą.
|
||||
Steer-backlog oznacza, że po sterowanym uruchomieniu możesz otrzymać odpowiedź followup, więc
|
||||
powierzchnie streamingowe mogą wyglądać jak duplikaty. Preferuj `collect`/`steer`, jeśli chcesz
|
||||
jednej odpowiedzi na wiadomość przychodzącą.
|
||||
|
||||
Informacje o czasie i zachowaniu zależności specyficznych dla środowiska uruchomieniowego znajdziesz w
|
||||
[Kolejce sterowania](/pl/concepts/queue-steering).
|
||||
Informacje o czasie działania i zachowaniu zależności specyficznym dla środowiska wykonawczego znajdziesz w
|
||||
[Kolejka sterowania](/pl/concepts/queue-steering).
|
||||
|
||||
Konfiguruj globalnie lub per kanał przez `messages.queue`:
|
||||
Skonfiguruj globalnie lub dla kanału przez `messages.queue`:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -78,31 +78,30 @@ Konfiguruj globalnie lub per kanał przez `messages.queue`:
|
||||
|
||||
## Opcje kolejki
|
||||
|
||||
Opcje mają zastosowanie do `followup`, `collect` i `steer-backlog` (oraz do `steer` lub starszego `queue`, gdy sterowanie wraca do follow-up):
|
||||
Opcje dotyczą `followup`, `collect` i `steer-backlog` (oraz `steer` lub starszego `queue`, gdy sterowanie przechodzi awaryjnie do followup):
|
||||
|
||||
- `debounceMs`: okres ciszy przed opróżnieniem follow-upów w kolejce. Same liczby oznaczają milisekundy; jednostki `ms`, `s`, `m`, `h` i `d` są akceptowane przez opcje `/queue`.
|
||||
- `cap`: maksymalna liczba wiadomości w kolejce na sesję. Wartości poniżej `1` są ignorowane.
|
||||
- `drop: "summarize"`: domyślne. Usuwa najstarsze wpisy z kolejki według potrzeb, zachowuje zwięzłe podsumowania i wstrzykuje je jako syntetyczny prompt follow-up.
|
||||
- `drop: "old"`: usuwa najstarsze wpisy z kolejki według potrzeb, bez zachowywania podsumowań.
|
||||
- `debounceMs`: okno ciszy przed opróżnieniem zakolejkowanych followupów. Same liczby oznaczają milisekundy; jednostki `ms`, `s`, `m`, `h` i `d` są akceptowane przez opcje `/queue`.
|
||||
- `cap`: maksymalna liczba zakolejkowanych wiadomości na sesję. Wartości poniżej `1` są ignorowane.
|
||||
- `drop: "summarize"`: domyślne. Odrzuca najstarsze zakolejkowane wpisy w razie potrzeby, zachowuje kompaktowe podsumowania i wstrzykuje je jako syntetyczny prompt followup.
|
||||
- `drop: "old"`: odrzuca najstarsze zakolejkowane wpisy w razie potrzeby, bez zachowywania podsumowań.
|
||||
- `drop: "new"`: odrzuca najnowszą wiadomość, gdy kolejka jest już pełna.
|
||||
|
||||
Domyślne wartości: `debounceMs: 500`, `cap: 20`, `drop: summarize`.
|
||||
|
||||
## Pierwszeństwo
|
||||
|
||||
Przy wyborze trybu OpenClaw rozstrzyga:
|
||||
Przy wyborze trybu OpenClaw rozstrzyga kolejno:
|
||||
|
||||
1. Wbudowane lub zapisane nadpisanie `/queue` dla sesji.
|
||||
2. `messages.queue.byChannel.<channel>`.
|
||||
3. `messages.queue.mode`.
|
||||
4. Domyślne `steer`.
|
||||
|
||||
Dla opcji wbudowane lub zapisane opcje `/queue` mają pierwszeństwo nad konfiguracją. Następnie
|
||||
stosowane są opóźnienie specyficzne dla kanału (`messages.queue.debounceMsByChannel`), domyślne
|
||||
opóźnienia Plugin, globalne opcje `messages.queue` oraz wbudowane wartości domyślne.
|
||||
`cap` i `drop` są opcjami globalnymi/sesyjnymi, a nie kluczami konfiguracji per kanał.
|
||||
Dla opcji wbudowane lub zapisane opcje `/queue` mają pierwszeństwo przed konfiguracją. Następnie
|
||||
stosowane są opóźnienie debounce specyficzne dla kanału (`messages.queue.debounceMsByChannel`), domyślne wartości
|
||||
debounce Plugin, globalne opcje `messages.queue` i wbudowane wartości domyślne. `cap` i `drop` są opcjami globalnymi/sesyjnymi, a nie kluczami konfiguracji dla kanału.
|
||||
|
||||
## Nadpisania per sesja
|
||||
## Nadpisania dla sesji
|
||||
|
||||
- Wyślij `/queue <mode>` jako samodzielne polecenie, aby zapisać tryb dla bieżącej sesji.
|
||||
- Opcje można łączyć: `/queue collect debounce:0.5s cap:25 drop:summarize`
|
||||
@ -111,19 +110,20 @@ opóźnienia Plugin, globalne opcje `messages.queue` oraz wbudowane wartości do
|
||||
## Zakres i gwarancje
|
||||
|
||||
- Dotyczy uruchomień agentów automatycznych odpowiedzi we wszystkich kanałach przychodzących, które używają potoku odpowiedzi Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat itd.).
|
||||
- Domyślny pas (`main`) obejmuje cały proces dla ruchu przychodzącego i głównych Heartbeat; ustaw `agents.defaults.maxConcurrent`, aby zezwolić na wiele sesji równolegle.
|
||||
- Mogą istnieć dodatkowe pasy (np. `cron`, `cron-nested`, `nested`, `subagent`), aby zadania w tle mogły działać równolegle bez blokowania odpowiedzi przychodzących. Izolowane tury agentów Cron trzymają slot `cron`, podczas gdy ich wewnętrzne wykonanie agenta używa `cron-nested`; oba używają `cron.maxConcurrentRuns`. Współdzielone przepływy nie-Cron `nested` zachowują własne zachowanie pasa. Te odłączone uruchomienia są śledzone jako [zadania w tle](/pl/automation/tasks).
|
||||
- Pasy per sesja gwarantują, że tylko jedno uruchomienie agenta naraz dotyka danej sesji.
|
||||
- Brak zewnętrznych zależności lub wątków roboczych w tle; czysty TypeScript + obietnice.
|
||||
- Domyślny tor (`main`) jest ogólny dla procesu dla przychodzących + głównych Heartbeat; ustaw `agents.defaults.maxConcurrent`, aby pozwolić na wiele sesji równolegle.
|
||||
- Mogą istnieć dodatkowe tory (np. `cron`, `cron-nested`, `nested`, `subagent`), aby zadania w tle mogły działać równolegle bez blokowania odpowiedzi przychodzących. Izolowane tury agenta Cron zajmują slot `cron`, podczas gdy ich wewnętrzne wykonanie agenta używa `cron-nested`; oba używają `cron.maxConcurrentRuns`. Współdzielone przepływy `nested` inne niż cron zachowują własne zachowanie toru. Te odłączone uruchomienia są śledzone jako [zadania w tle](/pl/automation/tasks).
|
||||
- Tory dla sesji gwarantują, że tylko jedno uruchomienie agenta dotyka danej sesji naraz.
|
||||
- Brak zewnętrznych zależności lub wątków workerów w tle; czysty TypeScript + obietnice.
|
||||
|
||||
## Rozwiązywanie problemów
|
||||
|
||||
- Jeśli polecenia wydają się zablokowane, włącz szczegółowe logi i szukaj wierszy „queued for …ms”, aby potwierdzić, że kolejka się opróżnia.
|
||||
- Jeśli potrzebujesz głębokości kolejki, włącz szczegółowe logi i obserwuj wiersze czasu kolejki.
|
||||
- Gdy diagnostyka jest włączona, sesje pozostające w `processing` dłużej niż `diagnostics.stuckSessionWarnMs` zapisują ostrzeżenie o zablokowanej sesji. Aktywne uruchomienia osadzone, aktywne operacje odpowiedzi i aktywne zadania pasa domyślnie pozostają tylko ostrzeżeniami; nieaktualna ewidencja startowa bez aktywnej pracy sesji może zwolnić dotknięty pas sesji, aby praca w kolejce mogła się opróżnić.
|
||||
- Jeśli potrzebujesz głębokości kolejki, włącz szczegółowe logi i obserwuj wiersze z czasem kolejki.
|
||||
- Uruchomienia serwera aplikacji Codex, które akceptują turę, a potem przestają emitować postęp, są przerywane przez adapter Codex, aby aktywny tor sesji mógł zostać zwolniony zamiast czekać na limit czasu zewnętrznego uruchomienia.
|
||||
- Gdy diagnostyka jest włączona, sesje pozostające w `processing` po `diagnostics.stuckSessionWarnMs` logują ostrzeżenie o zablokowanej sesji. Aktywne osadzone uruchomienia, aktywne operacje odpowiedzi i aktywne zadania toru domyślnie pozostają wyłącznie ostrzeżeniami; przestarzała ewidencja startowa bez aktywnej pracy sesji może zwolnić dotknięty tor sesji, aby zakolejkowana praca została opróżniona.
|
||||
|
||||
## Powiązane
|
||||
|
||||
- [Zarządzanie sesją](/pl/concepts/session)
|
||||
- [Zarządzanie sesjami](/pl/concepts/session)
|
||||
- [Kolejka sterowania](/pl/concepts/queue-steering)
|
||||
- [Zasady ponawiania](/pl/concepts/retry)
|
||||
- [Polityka ponawiania](/pl/concepts/retry)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -4,55 +4,56 @@ read_when:
|
||||
summary: Jak uruchamiać testy lokalnie (vitest) i kiedy używać trybów force/coverage
|
||||
title: Testy
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T10:17:40Z"
|
||||
generated_at: "2026-04-30T18:38:59Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 9328d6f0383b5067fa8bb5d0f1bf22a3b9048a267908bf85167842ddc3d12e42
|
||||
source_hash: 131f2bad3b2806d28394213cec38d632d106ddbf8ff04d06345ab8046fb8bcf2
|
||||
source_path: reference/test.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
- Pełny zestaw testowy (zestawy testów, testy na żywo, Docker): [Testowanie](/pl/help/testing)
|
||||
- Pełny zestaw testowy (zestawy, na żywo, Docker): [Testowanie](/pl/help/testing)
|
||||
|
||||
- `pnpm test:force`: Zabija każdy zaległy proces Gateway zajmujący domyślny port kontrolny, a następnie uruchamia pełny zestaw Vitest z izolowanym portem Gateway, aby testy serwera nie kolidowały z działającą instancją. Użyj tego, gdy wcześniejsze uruchomienie Gateway pozostawiło port 18789 zajęty.
|
||||
- `pnpm test:coverage`: Uruchamia zestaw testów jednostkowych z pokryciem V8 (przez `vitest.unit.config.ts`). To bramka pokrycia jednostkowego dla wczytanych plików, a nie pokrycie wszystkich plików w całym repozytorium. Progi wynoszą 70% dla linii/funkcji/instrukcji i 55% dla gałęzi. Ponieważ `coverage.all` ma wartość false, bramka mierzy pliki wczytane przez zestaw pokrycia jednostkowego zamiast traktować każdy plik źródłowy z podzielonej ścieżki jako niepokryty.
|
||||
- `pnpm test:force`: Zabija wszelkie pozostające procesy Gateway trzymające domyślny port kontrolny, a następnie uruchamia pełny zestaw Vitest z odizolowanym portem Gateway, aby testy serwera nie kolidowały z uruchomioną instancją. Użyj tego, gdy wcześniejsze uruchomienie Gateway pozostawiło port 18789 zajęty.
|
||||
- `pnpm test:coverage`: Uruchamia zestaw jednostkowy z pokryciem V8 (przez `vitest.unit.config.ts`). To bramka pokrycia jednostkowego załadowanych plików, a nie pokrycie wszystkich plików w całym repozytorium. Progi wynoszą 70% dla wierszy/funkcji/instrukcji i 55% dla gałęzi. Ponieważ `coverage.all` ma wartość false, bramka mierzy pliki załadowane przez zestaw pokrycia jednostkowego zamiast traktować każdy plik źródłowy z podzielonych torów jako niepokryty.
|
||||
- `pnpm test:coverage:changed`: Uruchamia pokrycie jednostkowe tylko dla plików zmienionych od `origin/main`.
|
||||
- `pnpm test:changed`: tani, inteligentny przebieg testów zmian. Uruchamia precyzyjne cele z bezpośrednich edycji testów, sąsiadujących plików `*.test.ts`, jawnych mapowań źródeł i lokalnego grafu importów. Szerokie zmiany konfiguracji/pakietów są pomijane, chyba że mapują się na precyzyjne testy.
|
||||
- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: jawny szeroki przebieg testów zmian. Użyj go, gdy edycja uprzęży testowej/konfiguracji/pakietu powinna wrócić do szerszego zachowania Vitest dla zmienionych testów.
|
||||
- `pnpm changed:lanes`: pokazuje ścieżki architektoniczne wyzwalane przez różnicę względem `origin/main`.
|
||||
- `pnpm check:changed`: uruchamia inteligentną bramkę sprawdzania zmian dla różnicy względem `origin/main`. Uruchamia typecheck, lint i komendy ochronne dla dotkniętych ścieżek architektonicznych, ale nie uruchamia testów Vitest. Użyj `pnpm test:changed` albo jawnego `pnpm test <target>` jako dowodu testowego.
|
||||
- `pnpm test`: kieruje jawne cele plików/katalogów przez zakresowe ścieżki Vitest. Przebiegi bez celu używają stałych grup shardów i rozwijają się do konfiguracji liści dla lokalnego wykonania równoległego; grupa rozszerzeń zawsze rozwija się do konfiguracji shardów dla poszczególnych rozszerzeń zamiast jednego ogromnego procesu projektu głównego.
|
||||
- Przebiegi wrappera testów kończą się krótkim podsumowaniem `[test] passed|failed|skipped ... in ...`. Własna linia czasu trwania Vitest pozostaje szczegółem dla shardu.
|
||||
- Wspólny stan testowy OpenClaw: używaj `src/test-utils/openclaw-test-state.ts` z Vitest, gdy test potrzebuje izolowanego `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, fixture konfiguracji, workspace, katalogu agenta albo magazynu profili uwierzytelniania.
|
||||
- Pomocniki E2E procesów: używaj `test/helpers/openclaw-test-instance.ts`, gdy test E2E na poziomie procesu Vitest potrzebuje działającego Gateway, środowiska CLI, przechwytywania logów i sprzątania w jednym miejscu.
|
||||
- Pomocniki Docker/Bash E2E: ścieżki, które źródłują `scripts/lib/docker-e2e-image.sh`, mogą przekazać `docker_e2e_test_state_shell_b64 <label> <scenario>` do kontenera i zdekodować to za pomocą `scripts/lib/openclaw-e2e-instance.sh`; skrypty z wieloma katalogami domowymi mogą przekazać `docker_e2e_test_state_function_b64` i wywołać `openclaw_test_state_create <label> <scenario>` w każdym przepływie. Wywołujący niższego poziomu mogą użyć `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` dla fragmentu powłoki w kontenerze albo `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` dla źródłowalnego pliku środowiska hosta. `--` przed `create` zapobiega traktowaniu `--env-file` jako flagi Node przez nowsze runtime Node. Ścieżki Docker/Bash uruchamiające Gateway mogą źródłować `scripts/lib/openclaw-e2e-instance.sh` wewnątrz kontenera dla rozwiązywania entrypointu, startu mockowanego OpenAI, uruchamiania Gateway na pierwszym planie/w tle, sond gotowości, eksportu środowiska stanu, zrzutów logów i sprzątania procesów.
|
||||
- Pełne przebiegi shardów, przebiegi rozszerzeń i wzorców include aktualizują lokalne dane czasów w `.artifacts/vitest-shard-timings.json`; późniejsze przebiegi całych konfiguracji używają tych czasów do równoważenia wolnych i szybkich shardów. Shardy CI z wzorcem include dopisują nazwę shardu do klucza czasu, co utrzymuje widoczność czasów filtrowanych shardów bez zastępowania danych czasów całych konfiguracji. Ustaw `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, aby zignorować lokalny artefakt czasów.
|
||||
- Wybrane pliki testowe `plugin-sdk` i `commands` są teraz kierowane przez dedykowane lekkie ścieżki, które zachowują tylko `test/setup.ts`, pozostawiając przypadki ciężkie runtime w ich istniejących ścieżkach.
|
||||
- Pliki źródłowe z sąsiadującymi testami mapują się najpierw na ten sąsiadujący test, zanim wrócą do szerszych globów katalogów. Edycje pomocników pod `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` i `src/plugins/contracts` używają lokalnego grafu importów do uruchamiania importujących testów zamiast szerokiego uruchamiania każdego shardu, gdy ścieżka zależności jest precyzyjna.
|
||||
- `auto-reply` dzieli się teraz także na trzy dedykowane konfiguracje (`core`, `top-level`, `reply`), aby uprząż odpowiedzi nie dominowała nad lżejszymi testami statusu/tokenów/pomocników najwyższego poziomu.
|
||||
- Bazowa konfiguracja Vitest domyślnie używa teraz `pool: "threads"` i `isolate: false`, ze współdzielonym nieizolowanym runnerem włączonym w konfiguracjach repozytorium.
|
||||
- `pnpm test:changed`: tani, inteligentny przebieg testów zmian. Uruchamia precyzyjne cele z bezpośrednich edycji testów, sąsiednich plików `*.test.ts`, jawnych mapowań źródeł oraz lokalnego grafu importów. Szerokie zmiany konfiguracji/pakietów są pomijane, chyba że mapują się na precyzyjne testy.
|
||||
- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: jawny szeroki przebieg testów zmian. Użyj go, gdy edycja uprzęży testowej/konfiguracji/pakietu powinna wrócić do szerszego zachowania testów zmian Vitest.
|
||||
- `pnpm changed:lanes`: pokazuje tory architektoniczne uruchamiane przez różnicę względem `origin/main`.
|
||||
- `pnpm check:changed`: uruchamia inteligentną bramkę sprawdzania zmian dla różnicy względem `origin/main`. Uruchamia typecheck, lint i polecenia strażników dla dotkniętych torów architektonicznych, ale nie uruchamia testów Vitest. Użyj `pnpm test:changed` albo jawnego `pnpm test <target>` jako dowodu testowego.
|
||||
- `pnpm test`: kieruje jawne cele plików/katalogów przez zakresowe tory Vitest. Uruchomienia bez celu używają stałych grup shardów i rozwijają się do konfiguracji liści dla lokalnego wykonania równoległego; grupa rozszerzeń zawsze rozwija się do konfiguracji shardów per rozszerzenie zamiast jednego ogromnego procesu projektu głównego.
|
||||
- Uruchomienia wrappera testów kończą się krótkim podsumowaniem `[test] passed|failed|skipped ... in ...`. Własny wiersz czasu trwania Vitest pozostaje szczegółem per shard.
|
||||
- Współdzielony stan testów OpenClaw: użyj `src/test-utils/openclaw-test-state.ts` z Vitest, gdy test potrzebuje odizolowanego `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, fikstury konfiguracji, workspace, katalogu agenta albo magazynu profili auth.
|
||||
- Pomocniki E2E procesów: użyj `test/helpers/openclaw-test-instance.ts`, gdy test E2E na poziomie procesu Vitest potrzebuje działającego Gateway, środowiska CLI, przechwytywania logów i sprzątania w jednym miejscu.
|
||||
- Pomocniki E2E Docker/Bash: tory, które źródłują `scripts/lib/docker-e2e-image.sh`, mogą przekazać `docker_e2e_test_state_shell_b64 <label> <scenario>` do kontenera i zdekodować go przez `scripts/lib/openclaw-e2e-instance.sh`; skrypty multi-home mogą przekazać `docker_e2e_test_state_function_b64` i wywołać `openclaw_test_state_create <label> <scenario>` w każdym przepływie. Wywołujący niższego poziomu mogą użyć `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` dla fragmentu powłoki w kontenerze albo `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` dla źródłowalnego pliku środowiska hosta. `--` przed `create` powstrzymuje nowsze runtime'y Node przed traktowaniem `--env-file` jako flagi Node. Tory Docker/Bash uruchamiające Gateway mogą źródłować `scripts/lib/openclaw-e2e-instance.sh` wewnątrz kontenera dla rozwiązywania entrypointu, startu mock OpenAI, uruchamiania Gateway na pierwszym planie/w tle, prób gotowości, eksportu środowiska stanu, zrzutów logów i sprzątania procesów.
|
||||
- Pełne, rozszerzeniowe i include-pattern uruchomienia shardów aktualizują lokalne dane czasów w `.artifacts/vitest-shard-timings.json`; późniejsze uruchomienia całych konfiguracji używają tych czasów do równoważenia wolnych i szybkich shardów. Shardy CI include-pattern dopisują nazwę sharda do klucza czasu, co utrzymuje widoczność czasów filtrowanych shardów bez zastępowania danych czasów całej konfiguracji. Ustaw `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, aby zignorować lokalny artefakt czasów.
|
||||
- Wybrane pliki testowe `plugin-sdk` i `commands` są teraz kierowane przez dedykowane lekkie tory, które zachowują tylko `test/setup.ts`, pozostawiając przypadki ciężkie runtime'owo na ich istniejących torach.
|
||||
- Pliki źródłowe z sąsiednimi testami mapują się najpierw na ten sąsiedni test, zanim wrócą do szerszych globów katalogów. Edycje pomocników pod `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` i `src/plugins/contracts` używają lokalnego grafu importów, aby uruchamiać testy importujące zamiast szeroko uruchamiać każdy shard, gdy ścieżka zależności jest precyzyjna.
|
||||
- `auto-reply` dzieli się teraz także na trzy dedykowane konfiguracje (`core`, `top-level`, `reply`), aby uprząż odpowiedzi nie dominowała lżejszych testów statusu/tokenów/pomocników najwyższego poziomu.
|
||||
- Bazowa konfiguracja Vitest ma teraz domyślnie `pool: "threads"` i `isolate: false`, ze współdzielonym nieizolowanym runnerem włączonym w konfiguracjach repozytorium.
|
||||
- `pnpm test:channels` uruchamia `vitest.channels.config.ts`.
|
||||
- `pnpm test:extensions` i `pnpm test extensions` uruchamiają wszystkie shardy rozszerzeń/Plugin. Ciężkie Plugin kanałowe, Plugin przeglądarki i OpenAI uruchamiają się jako dedykowane shardy; inne grupy Plugin pozostają zbatchowane. Użyj `pnpm test extensions/<id>` dla jednej ścieżki dołączonego Plugin.
|
||||
- `pnpm test:perf:imports`: włącza raportowanie czasu trwania importów Vitest i rozbicia importów, nadal używając zakresowego routingu ścieżek dla jawnych celów plików/katalogów.
|
||||
- `pnpm test:perf:imports:changed`: takie samo profilowanie importów, ale tylko dla plików zmienionych od `origin/main`.
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmarkuje routowaną ścieżkę trybu zmian względem natywnego przebiegu projektu głównego dla tej samej zatwierdzonej różnicy git.
|
||||
- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżący zestaw zmian worktree bez wcześniejszego commitowania.
|
||||
- `pnpm test:extensions` i `pnpm test extensions` uruchamiają wszystkie shardy rozszerzeń/pluginów. Ciężkie pluginy kanałów, plugin przeglądarki i OpenAI działają jako dedykowane shardy; inne grupy pluginów pozostają batched. Użyj `pnpm test extensions/<id>` dla jednego toru bundled plugin.
|
||||
- `pnpm test:perf:imports`: włącza raportowanie czasu trwania importów Vitest i rozbicia importów, nadal używając zakresowego kierowania torów dla jawnych celów plików/katalogów.
|
||||
- `pnpm test:perf:imports:changed`: to samo profilowanie importów, ale tylko dla plików zmienionych od `origin/main`.
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` benchmarkuje ścieżkę kierowanego trybu zmian względem natywnego uruchomienia projektu głównego dla tej samej zatwierdzonej różnicy git.
|
||||
- `pnpm test:perf:changed:bench -- --worktree` benchmarkuje bieżący zestaw zmian worktree bez wcześniejszego commitu.
|
||||
- `pnpm test:perf:profile:main`: zapisuje profil CPU dla głównego wątku Vitest (`.artifacts/vitest-main-profile`).
|
||||
- `pnpm test:perf:profile:runner`: zapisuje profile CPU i heap dla runnera jednostkowego (`.artifacts/vitest-runner-profile`).
|
||||
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: uruchamia każdą liściową konfigurację Vitest pełnego zestawu szeregowo i zapisuje pogrupowane dane czasu trwania oraz artefakty JSON/logów dla konfiguracji. Test Performance Agent używa tego jako baseline przed próbą naprawy wolnych testów.
|
||||
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: porównuje pogrupowane raporty po zmianie ukierunkowanej na wydajność.
|
||||
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: uruchamia każdą liściową konfigurację Vitest pełnego zestawu szeregowo i zapisuje pogrupowane dane czasów oraz artefakty JSON/log per konfiguracja. Test Performance Agent używa tego jako swojej bazowej linii przed próbą napraw wolnych testów.
|
||||
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: porównuje pogrupowane raporty po zmianie skupionej na wydajności.
|
||||
- Integracja Gateway: opt-in przez `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` albo `pnpm test:gateway`.
|
||||
- `pnpm test:e2e`: Uruchamia testy dymne end-to-end Gateway (parowanie wielu instancji WS/HTTP/node). Domyślnie używa `threads` + `isolate: false` z adaptacyjnymi workerami w `vitest.e2e.config.ts`; dostrój za pomocą `OPENCLAW_E2E_WORKERS=<n>` i ustaw `OPENCLAW_E2E_VERBOSE=1` dla szczegółowych logów.
|
||||
- `pnpm test:live`: Uruchamia testy live providerów (minimax/zai). Wymaga kluczy API i `LIVE=1` (albo specyficznego dla providera `*_LIVE_TEST=1`), aby odblokować pominięcie.
|
||||
- `pnpm test:docker:all`: Buduje współdzielony obraz testów live, pakuje OpenClaw raz jako tarball npm, buduje/ponownie używa surowego obrazu runnera Node/Git oraz obrazu funkcjonalnego, który instaluje ten tarball w `/app`, a następnie uruchamia ścieżki dymne Docker z `OPENCLAW_SKIP_DOCKER_BUILD=1` przez ważony scheduler. Surowy obraz (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) jest używany dla ścieżek instalatora/aktualizacji/zależności Plugin; te ścieżki montują wstępnie zbudowany tarball zamiast używać skopiowanych źródeł repozytorium. Obraz funkcjonalny (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) jest używany dla zwykłych ścieżek funkcjonalności zbudowanej aplikacji. `scripts/package-openclaw-for-docker.mjs` jest jedynym lokalnym/CI pakowaczem pakietu i waliduje tarball oraz `dist/postinstall-inventory.json`, zanim Docker go zużyje. Definicje ścieżek Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`; logika planera znajduje się w `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` wykonuje wybrany plan. `node scripts/test-docker-all.mjs --plan-json` emituje posiadany przez scheduler plan CI dla wybranych ścieżek, rodzajów obrazów, potrzeb pakietu/obrazu live, scenariuszy stanu i kontroli poświadczeń bez budowania ani uruchamiania Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` kontroluje sloty procesów i domyślnie wynosi 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` kontroluje pulę końcową wrażliwą na providerów i domyślnie wynosi 10. Limity ciężkich ścieżek domyślnie wynoszą `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` i `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; limity providerów domyślnie wynoszą jedną ciężką ścieżkę na providera przez `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` i `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Użyj `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` albo `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` dla większych hostów. Jeśli jedna ścieżka przekroczy efektywny limit wagi lub zasobów na hoście o niskiej równoległości, nadal może wystartować z pustej puli i będzie działać sama, aż zwolni pojemność. Starty ścieżek są domyślnie rozłożone co 2 sekundy, aby uniknąć lokalnych burz tworzenia w demonie Docker; nadpisz przez `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner domyślnie wykonuje preflight Docker, czyści nieaktualne kontenery OpenClaw E2E, emituje status aktywnych ścieżek co 30 sekund, współdzieli cache narzędzi CLI providerów między zgodnymi ścieżkami, ponawia przejściowe awarie providerów live domyślnie raz (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) i przechowuje czasy ścieżek w `.artifacts/docker-tests/lane-timings.json` dla kolejności od najdłuższych w późniejszych przebiegach. Użyj `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, aby wydrukować manifest ścieżek bez uruchamiania Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>`, aby dostroić wyjście statusu, albo `OPENCLAW_DOCKER_ALL_TIMINGS=0`, aby wyłączyć ponowne użycie czasów. Użyj `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` tylko dla deterministycznych/lokalnych ścieżek albo `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` tylko dla ścieżek providerów live; aliasy pakietów to `pnpm test:docker:local:all` i `pnpm test:docker:live:all`. Tryb tylko live łączy główne i końcowe ścieżki live w jedną pulę od najdłuższych, aby buckety providerów mogły pakować pracę Claude, Codex i Gemini razem. Runner przestaje planować nowe pulowane ścieżki po pierwszej awarii, chyba że ustawiono `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, a każda ścieżka ma 120-minutowy awaryjny timeout nadpisywalny przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; wybrane ścieżki live/końcowe używają ciaśniejszych limitów dla ścieżek. Komendy konfiguracji Docker backendu CLI mają własny timeout przez `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (domyślnie 180). Logi dla ścieżek, `summary.json`, `failures.json` i czasy faz są zapisywane pod `.artifacts/docker-tests/<run-id>/`; użyj `pnpm test:docker:timings <summary.json>`, aby sprawdzić wolne ścieżki, oraz `pnpm test:docker:rerun <run-id|summary.json|failures.json>`, aby wydrukować tanie komendy ukierunkowanego ponownego przebiegu.
|
||||
- `pnpm test:docker:browser-cdp-snapshot`: Buduje kontener E2E źródłowy oparty na Chromium, uruchamia surowe CDP oraz izolowany Gateway, uruchamia `browser doctor --deep` i weryfikuje, że migawki ról CDP zawierają URL-e linków, elementy klikalne wypromowane przez kursor, referencje iframe i metadane ramek.
|
||||
- Sondy live Docker backendu CLI można uruchamiać jako skoncentrowane ścieżki, na przykład `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` albo `pnpm test:docker:live-cli-backend:codex:mcp`. Claude i Gemini mają odpowiadające aliasy `:resume` i `:mcp`.
|
||||
- `pnpm test:docker:openwebui`: Uruchamia zdockeryzowane OpenClaw + Open WebUI, loguje się przez Open WebUI, sprawdza `/api/models`, a następnie uruchamia prawdziwy proxowany chat przez `/api/chat/completions`. Wymaga używalnego klucza modelu live (na przykład OpenAI w `~/.profile`), pobiera zewnętrzny obraz Open WebUI i nie oczekuje się, że będzie stabilny w CI tak jak zwykłe zestawy unit/e2e.
|
||||
- `pnpm test:docker:mcp-channels`: Uruchamia seedowany kontener Gateway i drugi kontener klienta, który spawnuje `openclaw mcp serve`, a następnie weryfikuje routowane wykrywanie konwersacji, odczyty transkryptów, metadane załączników, zachowanie kolejki zdarzeń live, routing wysyłania wychodzącego oraz powiadomienia kanału i uprawnień w stylu Claude przez rzeczywisty most stdio. Asercja powiadomienia Claude odczytuje bezpośrednio surowe ramki MCP stdio, więc smoke odzwierciedla to, co most faktycznie emituje.
|
||||
- `pnpm test:e2e`: Uruchamia end-to-end smoke testy Gateway (parowanie multi-instance WS/HTTP/node). Domyślnie używa `threads` + `isolate: false` z adaptacyjnymi workerami w `vitest.e2e.config.ts`; dostrój przez `OPENCLAW_E2E_WORKERS=<n>` i ustaw `OPENCLAW_E2E_VERBOSE=1` dla szczegółowych logów.
|
||||
- `pnpm test:live`: Uruchamia testy live providerów (minimax/zai). Wymaga kluczy API i `LIVE=1` (albo provider-specific `*_LIVE_TEST=1`), aby odblokować pominięcie.
|
||||
- `pnpm test:docker:all`: Buduje współdzielony obraz live-test, pakuje OpenClaw raz jako tarball npm, buduje/używa ponownie gołego obrazu runnera Node/Git oraz obrazu funkcjonalnego instalującego ten tarball do `/app`, a następnie uruchamia tory smoke Docker z `OPENCLAW_SKIP_DOCKER_BUILD=1` przez ważony scheduler. Goły obraz (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) jest używany dla torów instalatora/aktualizacji/zależności pluginów; te tory montują wstępnie zbudowany tarball zamiast używać skopiowanych źródeł repozytorium. Obraz funkcjonalny (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) jest używany dla zwykłych torów funkcjonalności zbudowanej aplikacji. `scripts/package-openclaw-for-docker.mjs` jest pojedynczym lokalnym/CI packerem pakietu i waliduje tarball oraz `dist/postinstall-inventory.json`, zanim Docker go użyje. Definicje torów Docker znajdują się w `scripts/lib/docker-e2e-scenarios.mjs`; logika planera znajduje się w `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` wykonuje wybrany plan. `node scripts/test-docker-all.mjs --plan-json` emituje plan CI należący do schedulera dla wybranych torów, rodzajów obrazów, potrzeb pakietu/obrazu live, scenariuszy stanu i sprawdzeń poświadczeń bez budowania ani uruchamiania Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` kontroluje sloty procesów i domyślnie wynosi 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` kontroluje pulę końcową wrażliwą na providerów i domyślnie wynosi 10. Limity ciężkich torów domyślnie wynoszą `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` i `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; limity providerów domyślnie dopuszczają jeden ciężki tor na providera przez `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` i `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Użyj `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` albo `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` dla większych hostów. Jeśli jeden tor przekracza efektywny limit wagi lub zasobów na hoście o niskiej równoległości, może nadal wystartować z pustej puli i będzie działał sam, dopóki nie zwolni pojemności. Starty torów są domyślnie rozłożone co 2 sekundy, aby uniknąć lokalnych burz tworzenia w demonie Docker; nadpisz przez `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner domyślnie wykonuje preflight Docker, czyści stare kontenery E2E OpenClaw, emituje status aktywnego toru co 30 sekund, współdzieli cache narzędzi CLI providerów między kompatybilnymi torami, domyślnie ponawia przejściowe błędy live-provider raz (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) i przechowuje czasy torów w `.artifacts/docker-tests/lane-timings.json` dla kolejności od najdłuższych w późniejszych uruchomieniach. Użyj `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, aby wypisać manifest torów bez uruchamiania Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>`, aby dostroić wyjście statusu, albo `OPENCLAW_DOCKER_ALL_TIMINGS=0`, aby wyłączyć ponowne użycie czasów. Użyj `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` tylko dla deterministycznych/lokalnych torów albo `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` tylko dla torów live-provider; aliasy pakietów to `pnpm test:docker:local:all` i `pnpm test:docker:live:all`. Tryb live-only scala główne i końcowe tory live w jedną pulę od najdłuższych, aby kubełki providerów mogły pakować razem pracę Claude, Codex i Gemini. Runner przestaje planować nowe tory z puli po pierwszym błędzie, chyba że ustawiono `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, a każdy tor ma 120-minutowy fallback timeout możliwy do nadpisania przez `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; wybrane tory live/tail używają ciaśniejszych limitów per tor. Polecenia konfiguracji Docker backendu CLI mają własny timeout przez `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (domyślnie 180). Logi per tor, `summary.json`, `failures.json` i czasy faz są zapisywane pod `.artifacts/docker-tests/<run-id>/`; użyj `pnpm test:docker:timings <summary.json>`, aby sprawdzić wolne tory, oraz `pnpm test:docker:rerun <run-id|summary.json|failures.json>`, aby wypisać tanie ukierunkowane polecenia ponownego uruchomienia.
|
||||
- `pnpm test:docker:browser-cdp-snapshot`: Buduje źródłowy kontener E2E oparty na Chromium, uruchamia surowe CDP oraz odizolowany Gateway, uruchamia `browser doctor --deep` i weryfikuje, że snapshoty ról CDP zawierają URL-e linków, promowane przez kursor elementy klikalne, referencje iframe i metadane ramek.
|
||||
- Live sondy Docker backendu CLI można uruchamiać jako skupione tory, na przykład `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` albo `pnpm test:docker:live-cli-backend:codex:mcp`. Claude i Gemini mają odpowiadające aliasy `:resume` i `:mcp`.
|
||||
- `pnpm test:docker:openwebui`: Uruchamia zdockeryzowane OpenClaw + Open WebUI, loguje się przez Open WebUI, sprawdza `/api/models`, a następnie uruchamia prawdziwy proxied chat przez `/api/chat/completions`. Wymaga używalnego klucza modelu live (na przykład OpenAI w `~/.profile`), pobiera zewnętrzny obraz Open WebUI i nie oczekuje się, że będzie stabilne w CI tak jak zwykłe zestawy unit/e2e.
|
||||
- `pnpm test:docker:mcp-channels`: Uruchamia kontener Gateway z seedem i drugi kontener klienta, który spawnuje `openclaw mcp serve`, a następnie weryfikuje wykrywanie kierowanych rozmów, odczyty transkrypcji, metadane załączników, zachowanie kolejki zdarzeń live, kierowanie wysyłki wychodzącej oraz powiadomienia kanału i uprawnień w stylu Claude przez prawdziwy most stdio. Asercja powiadomienia Claude odczytuje bezpośrednio surowe ramki stdio MCP, aby smoke odzwierciedlał to, co most faktycznie emituje.
|
||||
- `pnpm test:docker:upgrade-survivor`: Instaluje spakowane archiwum tar OpenClaw na zabrudzonym fixture starego użytkownika, uruchamia aktualizację pakietu oraz nieinteraktywne polecenie doctor bez kluczy dostawcy ani kanału live, następnie uruchamia Gateway loopback i sprawdza, czy agenci, konfiguracja kanału, listy dozwolonych Plugin, pliki obszaru roboczego/sesji, przestarzały stan zależności wykonawczych Plugin, uruchamianie oraz status RPC pozostają zachowane.
|
||||
|
||||
## Lokalna bramka PR
|
||||
|
||||
Do lokalnych kontroli przed scaleniem PR i kontroli bramek uruchom:
|
||||
W przypadku lokalnych kontroli scalenia/bramki PR uruchom:
|
||||
|
||||
- `pnpm check:changed`
|
||||
- `pnpm check`
|
||||
@ -61,12 +62,12 @@ Do lokalnych kontroli przed scaleniem PR i kontroli bramek uruchom:
|
||||
- `pnpm test`
|
||||
- `pnpm check:docs`
|
||||
|
||||
Jeśli `pnpm test` sporadycznie zawodzi na obciążonym hoście, uruchom ponownie raz, zanim potraktujesz to jako regresję, a następnie wyizoluj problem za pomocą `pnpm test <path/to/test>`. Dla hostów z ograniczoną pamięcią użyj:
|
||||
Jeśli `pnpm test` niestabilnie zawiedzie na obciążonym hoście, uruchom ponownie raz, zanim uznasz to za regresję, a następnie odizoluj problem za pomocą `pnpm test <path/to/test>`. Dla hostów z ograniczoną pamięcią użyj:
|
||||
|
||||
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
|
||||
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
|
||||
|
||||
## Benchmark opóźnienia modeli (klucze lokalne)
|
||||
## Test opóźnień modelu (lokalne klucze)
|
||||
|
||||
Skrypt: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
|
||||
|
||||
@ -74,14 +75,14 @@ Użycie:
|
||||
|
||||
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
|
||||
- Opcjonalne zmienne środowiskowe: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
|
||||
- Domyślny prompt: „Odpowiedz jednym słowem: ok. Bez interpunkcji ani dodatkowego tekstu.”
|
||||
- Domyślne polecenie: „Odpowiedz jednym słowem: ok. Bez interpunkcji ani dodatkowego tekstu.”
|
||||
|
||||
Ostatnie uruchomienie (2025-12-31, 20 przebiegów):
|
||||
|
||||
- minimax mediana 1279 ms (min. 1114, maks. 2431)
|
||||
- opus mediana 2454 ms (min. 1224, maks. 3170)
|
||||
- mediana minimax 1279 ms (min. 1114, maks. 2431)
|
||||
- mediana opus 2454 ms (min. 1224, maks. 3170)
|
||||
|
||||
## Benchmark uruchamiania CLI
|
||||
## Test startu CLI
|
||||
|
||||
Skrypt: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
|
||||
|
||||
@ -109,23 +110,23 @@ Zestawy ustawień:
|
||||
- `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `tasks --json`, `tasks list --json`, `tasks audit --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
|
||||
- `all`: oba zestawy ustawień
|
||||
|
||||
Dane wyjściowe obejmują `sampleCount`, średnią, p50, p95, min./maks., rozkład kodów wyjścia/sygnałów oraz podsumowania maksymalnego RSS dla każdego polecenia. Opcjonalne `--cpu-prof-dir` / `--heap-prof-dir` zapisują profile V8 dla każdego przebiegu, dzięki czemu pomiary czasu i przechwytywanie profili używają tego samego harnessu.
|
||||
Dane wyjściowe obejmują `sampleCount`, średnią, p50, p95, min./maks., rozkład kodów wyjścia/sygnałów oraz podsumowania maksymalnego RSS dla każdego polecenia. Opcjonalne `--cpu-prof-dir` / `--heap-prof-dir` zapisuje profile V8 dla każdego przebiegu, dzięki czemu pomiar czasu i przechwytywanie profili używają tego samego środowiska testowego.
|
||||
|
||||
Konwencje zapisanych danych wyjściowych:
|
||||
Konwencje zapisywanych danych wyjściowych:
|
||||
|
||||
- `pnpm test:startup:bench:smoke` zapisuje ukierunkowany artefakt smoke w `.artifacts/cli-startup-bench-smoke.json`
|
||||
- `pnpm test:startup:bench:save` zapisuje artefakt pełnego zestawu w `.artifacts/cli-startup-bench-all.json` z użyciem `runs=5` i `warmup=1`
|
||||
- `pnpm test:startup:bench:update` odświeża wersjonowany fixture bazowy w `test/fixtures/cli-startup-bench.json` z użyciem `runs=5` i `warmup=1`
|
||||
- `pnpm test:startup:bench:update` odświeża zatwierdzoną w repozytorium bazową fiksturę w `test/fixtures/cli-startup-bench.json` z użyciem `runs=5` i `warmup=1`
|
||||
|
||||
Wersjonowany fixture:
|
||||
Zatwierdzona w repozytorium fikstura:
|
||||
|
||||
- `test/fixtures/cli-startup-bench.json`
|
||||
- Odśwież za pomocą `pnpm test:startup:bench:update`
|
||||
- Porównaj bieżące wyniki z fixture za pomocą `pnpm test:startup:bench:check`
|
||||
- Porównaj bieżące wyniki z fiksturą za pomocą `pnpm test:startup:bench:check`
|
||||
|
||||
## Onboarding E2E (Docker)
|
||||
|
||||
Docker jest opcjonalny; jest to potrzebne tylko do konteneryzowanych testów smoke onboardingu.
|
||||
Docker jest opcjonalny; jest to potrzebne tylko do skonteneryzowanych testów smoke onboardingu.
|
||||
|
||||
Pełny przepływ zimnego startu w czystym kontenerze Linux:
|
||||
|
||||
@ -133,11 +134,11 @@ Pełny przepływ zimnego startu w czystym kontenerze Linux:
|
||||
scripts/e2e/onboard-docker.sh
|
||||
```
|
||||
|
||||
Ten skrypt obsługuje interaktywny kreator przez pseudo-tty, weryfikuje pliki konfiguracji/przestrzeni roboczej/sesji, a następnie uruchamia Gateway i wykonuje `openclaw health`.
|
||||
Ten skrypt steruje interaktywnym kreatorem przez pseudo-tty, weryfikuje pliki konfiguracji/przestrzeni roboczej/sesji, a następnie uruchamia Gateway i wykonuje `openclaw health`.
|
||||
|
||||
## Smoke importu QR (Docker)
|
||||
|
||||
Zapewnia, że utrzymywany pomocnik runtime QR ładuje się w obsługiwanych środowiskach uruchomieniowych Docker Node (domyślnie Node 24, zgodnie z kompatybilnością Node 22):
|
||||
Zapewnia, że utrzymywany pomocnik runtime QR ładuje się w obsługiwanych środowiskach runtime Docker Node (domyślnie Node 24, zgodne Node 22):
|
||||
|
||||
```bash
|
||||
pnpm test:docker:qr
|
||||
|
||||
Loading…
Reference in New Issue
Block a user