openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-23 13:59:17 +00:00
parent 2023b2e52b
commit 021dbff758
2 changed files with 102 additions and 109 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

121
docs/uk/ci.md
View File

@ -1,100 +1,93 @@
---
read_when:
- Вам потрібно зрозуміти, чому завдання CI було або не було запущене
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
- Ви налагоджуєте збої перевірок GitHub Actions
summary: Граф завдань CI, межі перевірок і локальні еквіваленти команд
summary: Граф завдань CI, шлюзи області змін і локальні еквіваленти команд
title: Конвеєр CI
x-i18n:
generated_at: "2026-04-23T13:33:21Z"
generated_at: "2026-04-23T13:58:21Z"
model: gpt-5.4
provider: openai
source_hash: 730bba64e0867f41b47e4896f8255b6d23e6530bb91d349abb25b35a43152e9e
source_hash: c5a8ea0d8e428826169b0e6aced1caeb993106fe79904002125ace86b48cae1f
source_path: ci.md
workflow: 15
---
# Конвеєр CI
CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне визначення меж, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки.
CI запускається при кожному push до `main` і для кожного pull request. Він використовує розумне визначення області змін, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки.
QA Lab має окремі доріжки CI поза основним workflow з розумним визначенням меж. Workflow
`Parity gate` запускається для відповідних змін у PR і при ручному запуску; він
збирає приватне середовище виконання QA і порівнює агентні набори mock GPT-5.4 та Opus 4.6.
Workflow `QA-Lab - All Lanes` запускається щоночі для `main` і при
ручному запуску; він розгалужує mock parity gate, live Matrix lane і live
Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`,
а Telegram lane використовує оренди Convex. `OpenClaw Release
Checks` також запускає ті самі доріжки QA Lab перед погодженням релізу.
QA Lab має окремі смуги CI поза основним workflow із розумним визначенням області змін. Workflow `Parity gate` запускається для відповідних змін у PR і через manual dispatch; він збирає приватний runtime QA та порівнює агентні пакети mock GPT-5.4 і Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгалужує mock parity gate, live Matrix lane і live Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram lane використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі смуги QA Lab перед схваленням релізу.
## Огляд завдань
| Завдання | Призначення | Коли запускається |
| --------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
| `preflight` | Виявляє зміни лише в документації, змінені межі, змінені extensions і будує маніфест CI | Завжди для недрафтових push і PR |
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для недрафтових push і PR |
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisories npm | Завжди для недрафтових push і PR |
| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для недрафтових push і PR |
| `build-artifacts` | Збирає `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, релевантні до Node |
| `checks-fast-core` | Швидкі Linux-доріжки коректності, такі як перевірки bundled/plugin-contract/protocol | Зміни, релевантні до Node |
| `checks-fast-contracts-channels` | Шардовані перевірки channel contract зі стабільним агрегованим результатом перевірки | Зміни, релевантні до Node |
| `checks-node-extensions` | Повні шардовані тести bundled-plugin для всього набору extension | Зміни, релевантні до Node |
| `checks-node-core-test` | Шарди core Node test, за винятком channel, bundled, contract і extension доріжок | Зміни, релевантні до Node |
| `extension-fast` | Сфокусовані тести лише для змінених bundled plugins | Pull request зі змінами в extension |
| `check` | Шардований еквівалент основної локальної перевірки: production типи, lint, guard, test types і strict smoke | Зміни, релевантні до Node |
| `check-additional` | Шарди архітектури, меж, guard для extension-surface, package-boundary і gateway-watch | Зміни, релевантні до Node |
| `build-smoke` | Smoke-тести built-CLI і smoke перевірка пам’яті під час запуску | Зміни, релевантні до Node |
| `checks` | Верифікатор для channel test built-artifact плюс сумісність Node 22 лише для push | Зміни, релевантні до Node |
| `check-docs` | Форматування документації, lint і перевірки на биті посилання | Змінено документацію |
| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні до Python Skills |
| `checks-windows` | Windows-специфічні тестові доріжки | Зміни, релевантні до Windows |
| `macos-node` | Доріжка TypeScript test для macOS з використанням спільних built artifacts | Зміни, релевантні до macOS |
| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні до macOS |
| `android` | Android unit tests для обох flavor плюс одна збірка debug APK | Зміни, релевантні до Android |
| Завдання | Призначення | Коли запускається |
| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
| `preflight` | Визначає зміни лише в документації, змінені області, змінені extensions і будує CI-маніфест | Завжди для нечернеткових push і PR |
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR |
| `security-dependency-audit` | Аудит production lockfile без залежностей на основі advisories npm | Завжди для нечернеткових push і PR |
| `security-fast` | Обов’язковий агрегатор для швидких завдань безпеки | Завжди для нечернеткових push і PR |
| `build-artifacts` | Збирає `dist/`, Control UI, перевірки built artifacts і повторно використовувані downstream artifacts | Зміни, релевантні для Node |
| `checks-fast-core` | Швидкі смуги коректності Linux, такі як bundled/plugin-contract/protocol checks | Зміни, релевантні для Node |
| `checks-fast-contracts-channels` | Розшардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node |
| `checks-node-extensions` | Повні шарди тестів bundled plugins для всього набору extensions | Зміни, релевантні для Node |
| `checks-node-core-test` | Шарди основних Node-тестів, за винятком смуг каналів, bundled, контрактів і extensions | Зміни, релевантні для Node |
| `extension-fast` | Точкові тести лише для змінених bundled plugins | Pull request зі змінами в extensions |
| `check` | Розшардований еквівалент основного локального шлюзу: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
| `check-additional` | Шарди архітектури, меж, захисту extension-surface, package-boundary і gateway-watch | Зміни, релевантні для Node |
| `build-smoke` | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску | Зміни, релевантні для Node |
| `checks` | Верифікатор для тестів каналів built artifacts плюс сумісність Node 22 лише для push | Зміни, релевантні для Node |
| `check-docs` | Перевірки форматування документації, lint і битих посилань | Змінено документацію |
| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Skills на Python |
| `checks-windows` | Смуги тестів, специфічні для Windows | Зміни, релевантні для Windows |
| `macos-node` | Смуга TypeScript-тестів на macOS із використанням спільних built artifacts | Зміни, релевантні для macOS |
| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS |
| `android` | Android unit tests для обох flavor плюс одна збірка debug APK | Зміни, релевантні для Android |
## Порядок Fail-Fast
Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
Завдання впорядковані так, щоб дешеві перевірки завершувалися помилкою раніше, ніж запустяться дорогі:
1. `preflight` визначає, які доріжки взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються з помилкою швидко, не чекаючи важчих завдань артефактів і платформної матриці.
3. `build-artifacts` виконується паралельно зі швидкими Linux-доріжками, щоб downstream-споживачі могли стартувати, щойно спільна збірка готова.
4. Після цього розгалужуються важчі платформні та runtime-доріжки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` лише для PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
1. `preflight` вирішує, які смуги взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих завдань артефактів і платформної матриці.
3. `build-artifacts` виконується паралельно зі швидкими Linux-смугами, щоб downstream-споживачі могли стартувати щойно буде готова спільна збірка.
4. Після цього розгалужуються важчі платформні та runtime-смуги: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` лише для PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
Логіка меж міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`.
Редагування workflow CI перевіряє граф Node CI разом із lint для workflow, але саме по собі не примушує виконувати нативні збірки Windows, Android або macOS; ці платформні доріжки й далі залежать від змін у платформному коді.
Перевірки Windows Node обмежені Windows-специфічними process/path wrappers, npm/pnpm/UI runner helpers, конфігурацією package manager і поверхнями workflow CI, які запускають цю доріжку; не пов’язані зміни в коді, plugin, install-smoke і зміни лише в тестах залишаються на Linux Node доріжках, щоб не резервувати Windows worker на 16 vCPU для покриття, яке вже перевіряється звичайними test shards.
Окремий workflow `install-smoke` повторно використовує той самий скрипт меж через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, релевантних до install, packaging, container, production changes у bundled extension і поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke jobs. Зміни лише в тестах і документації не резервують Docker workers. Його smoke для QR package примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе ще перевіряє встановлення без повторного завантаження залежностей у кожному запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в цьому завданні, тож додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки. Локально `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image з `scripts/e2e/Dockerfile`, а потім паралельно запускає доріжки live/E2E smoke з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте стандартний паралелізм 4 через `OPENCLAW_DOCKER_ALL_PARALLELISM`. Доріжки, чутливі до запуску або провайдера, виконуються ексклюзивно після паралельного пулу. Повторно використовуваний workflow live/E2E наслідує шаблон спільного image, збираючи й публікуючи один Docker E2E image у GHCR з тегом SHA перед Docker matrix, а потім запускаючи матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Тести QR і installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Окреме завдання `docker-e2e-fast` запускає обмежений bundled-plugin Docker profile з тайм-аутом команди 120 секунд: відновлення залежностей setup-entry плюс ізоляція синтетичного збою bundled-loader. Повна bundled update/channel matrix залишається ручною/full-suite, оскільки виконує повторні реальні проходи npm update і doctor repair.
Логіка області змін міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`.
Зміни у workflow CI перевіряють граф Node CI плюс linting workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні смуги залишаються прив’язаними до змін у коді відповідних платформ.
Перевірки Windows Node прив’язані до специфічних для Windows wrappers для process/path, helper-утиліт npm/pnpm/UI runner, конфігурації package manager і поверхонь workflow CI, які запускають цю смугу; непов’язані зміни в коді, plugins, install-smoke і лише тестах залишаються на Linux Node lanes, щоб не резервувати 16-vCPU Windows worker для покриття, яке вже виконується звичайними test shards.
Окремий workflow `install-smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, пов’язаних із встановленням, пакуванням, контейнерами, production changes у bundled extension і основними поверхнями plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише в тестах і документації не резервують Docker workers. Його smoke для QR package примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе ще перевіряє встановлення без повторного завантаження залежностей у кожному запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в завданні, тому додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки. Локальний `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image з `scripts/e2e/Dockerfile`, а потім запускає смуги live/E2E паралельно з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову паралельність 4 через `OPENCLAW_DOCKER_ALL_PARALLELISM`. Локальний агрегатор типово припиняє планувати нові pooled lanes після першої помилки, а кожна смуга має timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Смуги, чутливі до запуску або provider, виконуються ексклюзивно після паралельного пулу. Повторно використовуваний workflow live/E2E віддзеркалює шаблон спільного image: спочатку будує й публікує один Docker E2E image у GHCR, позначений SHA, перед Docker matrix, а потім запускає matrix із `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований workflow live/E2E щодня запускає повний Docker-набір релізного шляху. Docker-тести QR та installer зберігають власні Dockerfile, орієнтовані на встановлення. Окреме завдання `docker-e2e-fast` запускає обмежений Docker-профіль bundled-plugin із timeout команди 120 секунд: repair залежностей setup-entry плюс ізоляцію синтетичних збоїв bundled-loader. Повна матриця bundled update/channel залишається manual/full-suite, тому що виконує повторні реальні проходи npm update і doctor repair.
Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широка платформна межа CI: зміни core production запускають core prod typecheck плюс core tests, зміни лише в core tests запускають лише core test typecheck/tests, зміни extension production запускають extension prod typecheck плюс extension tests, а зміни лише в extension tests запускають лише extension test typecheck/tests. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію на extension, тому що extension залежать від цих core contract. Version bumps лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно розширюються до всіх доріжок.
Логіка локальних changed lanes міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка область платформ CI: зміни в основному production-коді запускають typecheck основного production-коду плюс основні тести, зміни лише в основних тестах запускають лише typecheck/tests основних тестів, production changes в extensions запускають typecheck production-коду extensions плюс тести extensions, а зміни лише в тестах extensions запускають лише typecheck/tests тестів extensions. Зміни у публічному Plugin SDK або plugin-contract розширюють валідацію на extensions, тому що extensions залежать від цих основних контрактів. Підвищення версій лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config переводять виконання в безпечний режим усіх смуг.
Для push матриця `checks` додає доріжку `compat-node22`, яка запускається лише для push. Для pull request ця доріжка пропускається, і матриця залишається зосередженою на звичайних test/channel доріжках.
Для push матриця `checks` додає смугу `compat-node22`, яка запускається лише для push. Для pull request ця смуга пропускається, і матриця зосереджується на звичайних test/channel lanes.
Найповільніші сімейства Node test розділені або збалансовані так, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на шість зважених shard загалом, bundled plugin tests балансуються між шістьма extension workers, auto-reply працює як три збалансовані workers замість шести маленьких workers, а agentic gateway/plugin configs розподіляються між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої окремі конфігурації Vitest, а не спільний plugin catch-all. Широка доріжка agents використовує спільний file-parallel scheduler Vitest, оскільки для неї домінують імпорти/планування, а не один повільний test file. `runtime-config` запускається разом із shard infra core-runtime, щоб спільний runtime shard не утримував хвіст. `check-additional` тримає compile/canary-роботи package-boundary разом і відокремлює runtime topology architecture від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guard паралельно в межах одного завдання. Gateway watch, channel tests і shard core support-boundary запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі назви перевірок як легкі завдання-верифікатори й уникаючи двох додаткових Blacksmith workers та другої черги споживачів артефактів.
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. У flavor third-party немає окремого source set або manifest; його доріжка unit-test усе одно компілює цей flavor із прапорцями SMS/call-log BuildConfig, уникаючи при цьому дубльованого завдання пакування debug APK для кожного Android-релевантного push.
`extension-fast` є лише для PR, тому що push-запуски вже виконують повні шарди bundled plugin. Це дає швидкий зворотний зв’язок для changed-plugin під час review, не резервуючи додатковий Blacksmith worker у `main` для покриття, яке вже присутнє в `checks-node-extensions`.
Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим: контракти каналів розділяють покриття registry і core на шість зважених шардів загалом, тести bundled plugins балансуються між шістьма workers для extensions, auto-reply працює як три збалансовані workers замість шести дрібних workers, а конфігурації agentic gateway/plugin розподіляються по наявних agentic Node jobs лише для вихідного коду замість очікування built artifacts. Широкі тести browser, QA, media та різних plugins використовують свої окремі конфігурації Vitest замість спільного універсального набору plugin-тестів. Широка agents lane використовує спільний планувальник паралельного виконання файлів Vitest, оскільки в ній домінують імпорти/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із shard `infra core-runtime`, щоб спільний runtime shard не залишався найдовшим. `check-additional` утримує разом compile/canary роботу package-boundary та відокремлює архітектуру runtime topology від покриття gateway watch; shard захисту boundary запускає свої невеликі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і shard core support-boundary запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі назви перевірок як легкі завдання-верифікатори й водночас уникаючи двох додаткових workers Blacksmith і другої черги споживачів артефактів.
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Варіант third-party не має окремого source set або manifest; його смуга unit-тестів усе одно компілює цей flavor із прапорцями SMS/call-log BuildConfig, водночас уникаючи дубльованого завдання пакування debug APK при кожному push, релевантному для Android.
`extension-fast` є лише для PR, тому що push-запуски вже виконують повні шарди bundled plugin. Це зберігає швидкий зворотний зв’язок для змінених plugins під час рев’ю без резервування додаткового worker Blacksmith на `main` для покриття, яке вже присутнє в `checks-node-extensions`.
GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Сприймайте це як шум CI, якщо тільки найновіший запуск для того самого ref теж не завершується з помилкою. Агреговані shard checks використовують `!cancelled() && always()`, щоб вони все одно повідомляли про звичайні помилки shard, але не ставали в чергу після того, як увесь workflow уже було витіснено.
Ключ конкурентності CI версіонований (`CI-v7-*`), щоб GitHub-side zombie у старій групі черги не міг безкінечно блокувати новіші запуски main.
GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується помилкою. Агреговані shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні помилки shard, але не стають у чергу після того, як увесь workflow уже був витіснений.
Ключ concurrency для CI має версію (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
## Виконавці
| Виконавець | Завдання |
| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки channel contract, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агреговані верифікатори Node test, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди Linux Node test, шарди bundled plugin test, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тому 8 vCPU коштували дорожче, ніж давали вигоду; Docker-збірки install-smoke, де вартість часу очікування в черзі для 32 vCPU перевищувала отриману користь |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` |
| Виконавець | Завдання |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегатори (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, розшардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегатори `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує Ubuntu від GitHub, щоб матриця Blacksmith могла ставати в чергу раніше |
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди Linux Node-тестів, шарди тестів bundled plugins, `android` |
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який усе ще достатньо чутливий до CPU, тож 8 vCPU коштували дорожче, ніж заощаджували; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував дорожче, ніж заощаджував |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний варіант `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний варіант `macos-latest` |
## Локальні еквіваленти
```bash
pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD
pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane
pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guard
pnpm changed:lanes # перевірити локальний класифікатор changed lanes для origin/main...HEAD
pnpm check:changed # розумний локальний шлюз: changed typecheck/lint/tests за boundary lane
pnpm check # швидкий локальний шлюз: production tsgo + розшардований lint + паралельні швидкі guards
pnpm check:test-types
pnpm check:timed # та сама перевірка з таймінгами для кожного етапу
pnpm check:timed # той самий шлюз із таймінгами для кожного етапу
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
@ -102,6 +95,6 @@ pnpm test # тести vitest
pnpm test:channels
pnpm test:contracts:channels
pnpm check:docs # форматування документації + lint + биті посилання
pnpm build # зібрати dist, коли важливі доріжки CI artifact/build-smoke
pnpm build # зібрати dist, коли важливі смуги CI artifact/build-smoke
node scripts/ci-run-timings.mjs <run-id> # підсумувати загальний час, час у черзі та найповільніші завдання
```

90
docs/uk/reference/test.md
View File

@ -1,13 +1,13 @@
---
read_when:
- Запуск або виправлення тестів
summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage
summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage
title: Тести
x-i18n:
generated_at: "2026-04-23T13:33:21Z"
generated_at: "2026-04-23T13:58:08Z"
model: gpt-5.4
provider: openai
source_hash: 2897f6a58720b43c749dc7ea410369a529bb8f72c50f8d9e55f114bf39ccb1a9
source_hash: e0bcecb0868b3b68361e5ef78afc3170f2a481771bda8f7d54200b1d778d044a
source_path: reference/test.md
workflow: 15
---
@ -16,36 +16,36 @@ x-i18n:
- Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing)
- `pnpm test:force`: завершує будь-який завислий процес gateway, що утримує стандартний порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
- `pnpm test:coverage`: запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка unit-покриття для завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Порогові значення: 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit-покриття, замість того щоб вважати кожен файл вихідного коду в розбитих lane непокритим.
- `pnpm test:coverage:changed`: запускає unit-покриття лише для файлів, змінених відносно `origin/main`.
- `pnpm test:changed`: розгортає змінені git-шляхи у scoped lane Vitest, коли diff торкається лише routable файлів коду/тестів. Зміни конфігурації/налаштування, як і раніше, повертаються до нативного запуску root projects, щоб за потреби зміни у зв’язуванні перезапускали ширший набір.
- `pnpm changed:lanes`: показує архітектурні lane, які запускаються diff відносно `origin/main`.
- `pnpm check:changed`: запускає розумну перевірку changed gate для diff відносно `origin/main`. Вона запускає core-роботи разом із lane core-тестів, роботи extensions — разом із lane extension-тестів, зміни лише в тестах — лише з typecheck/tests для тестів, розширює зміни публічного Plugin SDK або plugin-contract до перевірки extensions, а також залишає підвищення версій лише в release metadata на таргетованих перевірках version/config/root-dependency.
- `pnpm test`: маршрутизує явно вказані цілі файлів/каталогів через scoped lane Vitest. Нетаргетовані запуски використовують фіксовані групи shard і розгортаються до leaf config для локального паралельного виконання; група extensions завжди розгортається до конфігурацій shard для кожного extension/plugin окремо, а не в один гігантський процес root-project.
- Повні запуски та запуски shard для extensions оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; пізніші запуски використовують ці таймінги для балансування повільних і швидких shard. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів.
- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі кейси на наявних lane.
- Вибрані допоміжні вихідні файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами у цих легких lane, тож невеликі зміни в helper не змушують повторно запускати важкі набори з runtime.
- `pnpm test:force`: Завершує всі завислі процеси gateway, що утримують типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив порт 18789 зайнятим.
- `pnpm test:coverage`: Запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка unit-покриття завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Порогові значення: 70% для рядків/функцій/інструкцій і 55% для гілок. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit-покриття, замість того щоб вважати кожен файл вихідного коду з розділених lane непокритим.
- `pnpm test:coverage:changed`: Запускає unit-покриття лише для файлів, змінених відносно `origin/main`.
- `pnpm test:changed`: розгортає змінені шляхи git у scoped Vitest lane, коли diff торкається лише routable файлів вихідного коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску root projects, щоб за потреби зміни в обв’язці запускали ширший повторний прогін.
- `pnpm changed:lanes`: показує архітектурні lane, які запускаються через diff відносно `origin/main`.
- `pnpm check:changed`: запускає розумну перевірку changed для diff відносно `origin/main`. Вона запускає core-частину разом із lane тестів core, роботу extension — із lane тестів extension, зміни лише в тестах — тільки з typecheck/tests для тестів, розширює зміни публічного Plugin SDK або plugin-contract до перевірки extension, а також залишає метадані релізу з оновленням лише версії на цільових перевірках version/config/root-dependency.
- `pnpm test`: маршрутизує явні цілі файлів/каталогів через scoped Vitest lane. Запуски без конкретної цілі використовують фіксовані групи shard і розгортаються до leaf configs для локального паралельного виконання; група extension завжди розгортається до конфігурацій shard для кожного extension/plugin, а не в один великий процес root-project.
- Повні запуски та запуски shard extension оновлюють локальні дані часу в `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці дані, щоб балансувати повільні й швидкі shard. Встановіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт часу.
- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane, які залишають лише `test/setup.ts`, а важкі з погляду runtime випадки залишаються на наявних lane.
- Вибрані допоміжні файли вихідного коду `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane, тож невеликі зміни в helper не спричиняють повторний запуск важких наборів, що спираються на runtime.
- `auto-reply` тепер також розділено на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper.
- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` та `isolate: false`, а спільний non-isolated runner увімкнено в конфігураціях по всьому репозиторію.
- Базова конфігурація Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в конфігураціях усього репозиторію.
- `pnpm test:channels` запускає `vitest.channels.config.ts`.
- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel extensions і OpenAI виконуються як окремі shard; інші групи extensions залишаються згрупованими. Використовуйте `pnpm test extensions/<id>` для одного lane bundled plugin.
- `pnpm test:perf:imports`: вмикає звіти Vitest про тривалість імпорту та розбивку імпортів, водночас зберігаючи маршрутизацію через scoped lane для явно вказаних цілей файлів/каталогів.
- `pnpm test:perf:imports:changed`: те саме профілювання імпортів, але лише для файлів, змінених відносно `origin/main`.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` виконує benchmark маршрутизованого шляху в changed-режимі проти нативного запуску root-project для того самого закоміченого git diff.
- `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного набору змін у worktree без попереднього коміту.
- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`).
- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel extension і OpenAI запускаються як окремі shard; інші групи extension залишаються згрупованими. Використовуйте `pnpm test extensions/<id>` для одного lane bundled plugin.
- `pnpm test:perf:imports`: вмикає звітність Vitest щодо тривалості імпорту та розбивки імпортів, водночас і надалі використовуючи scoped lane routing для явних цілей файлів/каталогів.
- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` вимірює продуктивність маршрутизованого шляху changed-mode порівняно з нативним запуском root-project для того самого закоміченого git diff.
- `pnpm test:perf:changed:bench -- --worktree` вимірює продуктивність поточного набору змін у worktree без попереднього коміту.
- `pnpm test:perf:profile:main`: записує CPU-профіль для головного потоку Vitest (`.artifacts/vitest-main-profile`).
- `pnpm test:perf:profile:runner`: записує профілі CPU + heap для unit runner (`.artifacts/vitest-runner-profile`).
- Інтеграція Gateway: вмикається явно через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (парування multi-instance WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=<n>`, а для докладних логів установіть `OPENCLAW_E2E_VERBOSE=1`.
- `pnpm test:live`: запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для провайдера `*_LIVE_TEST=1`), щоб зняти пропуск.
- `pnpm test:docker:all`: один раз збирає спільний образ live-тестів і образ Docker E2E, а потім запускає Docker smoke lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` із паралелізмом 4 за замовчуванням. Налаштовується через `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>`. Lane, чутливі до старту або провайдера, запускаються ексклюзивно після паралельного пулу. Логи для кожного lane записуються в `.artifacts/docker-tests/<run-id>/`.
- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потрібен придатний ключ live-моделі (наприклад, OpenAI у `~/.profile`), підтягується зовнішній образ Open WebUI, і цей сценарій не очікується стабільним у CI так, як звичайні набори unit/e2e.
- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із наповненими даними та другий клієнтський контейнер, який піднімає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані вкладень, поведінку черги live-подій, маршрутизацію вихідних надсилань і сповіщення про channel + permissions у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-фрейми безпосередньо, щоб smoke відображав те, що міст справді надсилає.
- Інтеграція Gateway: увімкнення через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
- `pnpm test:e2e`: Запускає наскрізні smoke-тести gateway (pairing кількох екземплярів WS/HTTP/node). Типово використовує `threads` + `isolate: false` з адаптивною кількістю worker у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=<n>`, а для докладних журналів встановіть `OPENCLAW_E2E_VERBOSE=1`.
- `pnpm test:live`: Запускає live-тести provider (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для provider `*_LIVE_TEST=1`) для зняття пропуску.
- `pnpm test:docker:all`: Один раз збирає спільний образ live-test і образ Docker E2E, а потім запускає Docker smoke lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` із типовим паралелізмом 4. Налаштовується через `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>`. Runner припиняє планувати нові lane у пулі після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожен lane має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Lane, чутливі до запуску або provider, виконуються ексклюзивно після паралельного пулу. Журнали для кожного lane записуються в `.artifacts/docker-tests/<run-id>/`.
- `pnpm test:docker:openwebui`: Запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live model (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не очікується настільки стабільним у CI, як звичайні набори unit/e2e.
- `pnpm test:docker:mcp-channels`: Запускає контейнер Gateway із підготовленими даними та другий контейнер-клієнт, який запускає `openclaw mcp serve`, а потім перевіряє пошук маршрутизованих розмов, читання транскриптів, метадані вкладень, поведінку live-черги подій, маршрутизацію вихідного надсилання та сповіщення про channel + permissions у стилі Claude через реальний міст stdio. Перевірка сповіщення Claude читає сирі stdio MCP-кадри напряму, щоб smoke відображав те, що міст фактично надсилає.
## Локальний PR gate
## Локальна перевірка PR
Для локальних перевірок перед злиттям PR запускайте:
Для локальних перевірок перед злиттям/проходженням PR запустіть:
- `pnpm check:changed`
- `pnpm check`
@ -54,12 +54,12 @@ x-i18n:
- `pnpm test`
- `pnpm check:docs`
Якщо `pnpm test` нестабільно проходить на навантаженому хості, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте проблему через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
Якщо `pnpm test` дає flaky-результат на завантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
## Benchmark затримки моделі (локальні ключі)
## Бенч затримки моделі (локальні ключі)
Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
@ -67,14 +67,14 @@ x-i18n:
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
- Необов’язкові змінні середовища: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
- Стандартний prompt: “Reply with a single word: ok. No punctuation or extra text.”
- Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків або додаткового тексту.”
Останній запуск (2025-12-31, 20 запусків):
Останній запуск (2025-12-31, 20 прогонів):
- median для minimax: 1279 мс (min 1114, max 2431)
- median для opus: 2454 мс (min 1224, max 3170)
- minimax median 1279ms (min 1114, max 2431)
- opus median 2454ms (min 1224, max 3170)
## Benchmark запуску CLI
## Бенч запуску CLI
Скрипт: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
@ -95,25 +95,25 @@ x-i18n:
- `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
- `pnpm tsx scripts/bench-cli-startup.ts --json`
Preset-и:
Набори preset:
- `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
- `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
- `all`: обидва preset-и
- `all`: обидва набори preset
Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і підсумки max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного запуску, тож вимірювання часу та збирання профілів використовують один і той самий harness.
Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного прогону, щоб вимірювання часу та збір профілів використовували один і той самий harness.
Домовленості щодо збережених результатів:
Угоди щодо збереженого виводу:
- `pnpm test:startup:bench:smoke` записує таргетований smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json`
- `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json`
- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json`, використовуючи `runs=5` і `warmup=1`
- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json`, використовуючи `runs=5` і `warmup=1`
Закомічений fixture:
- `test/fixtures/cli-startup-bench.json`
- Оновити можна через `pnpm test:startup:bench:update`
- Порівняти поточні результати з fixture можна через `pnpm test:startup:bench:check`
- Оновити через `pnpm test:startup:bench:update`
- Порівняти поточні результати з fixture через `pnpm test:startup:bench:check`
## Onboarding E2E (Docker)
@ -125,11 +125,11 @@ Docker необов’язковий; це потрібно лише для cont
scripts/e2e/onboard-docker.sh
```
Цей скрипт проходить інтерактивний майстер через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
Цей скрипт проводить interactive wizard через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
## Smoke для QR-імпорту (Docker)
## Smoke-тест імпорту QR (Docker)
Гарантує, що `qrcode-terminal` завантажується в підтримуваних Docker-рантаймах Node (Node 24 за замовчуванням, Node 22 сумісний):
Гарантує, що `qrcode-terminal` завантажується в підтримуваних runtime Node у Docker (типово Node 24, сумісний Node 22):
```bash
pnpm test:docker:qr