diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 4533232fe..acb36bea2 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,59 +1,27 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося - - Ви налагоджуєте збої в перевірках GitHub Actions -summary: Граф завдань CI, перевірки за областю змін і локальні еквіваленти команд -title: пайплайн CI + - Вам потрібно зрозуміти, чому завдання CI було або не було запущено + - Ви налагоджуєте збої перевірок GitHub Actions +summary: Граф завдань CI, шлюзи охоплення та локальні еквіваленти команд +title: Конвеєр CI x-i18n: - generated_at: "2026-04-26T21:31:07Z" + generated_at: "2026-04-26T21:58:21Z" model: gpt-5.4 provider: openai - source_hash: 2b60445c01b9cc30be075c37c04ae827f68f9b08550abc3bfde498f8660c6fc2 + source_hash: 3332c240435650af6f2cfe898d47bd7da8bdc58edb8dc8544699a741625d9b27 source_path: ci.md workflow: 15 --- -CI запускається під час кожного push до `main` і для кожного pull request. Він використовує розумне обмеження за областю змін, щоб пропускати дорогі завдання, коли змінено лише нерелевантні ділянки. +CI запускається при кожному пуші в `main` і при кожному pull request. Він використовує розумне визначення охоплення, щоб пропускати дорогі завдання, коли змінилися лише непов’язані частини. -QA Lab має окремі лінії CI поза основним робочим процесом із розумним обмеженням за областю змін. Робочий процес -`Parity gate` запускається для PR зі відповідними змінами та через manual dispatch; він -збирає приватне середовище виконання QA і порівнює агентні пакети mock GPT-5.5 та Opus 4.6. -Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і через -manual dispatch; він розгалужує mock parity gate, live-лінію Matrix і live-лінію -Telegram як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, -а лінія Telegram використовує оренди Convex. `OpenClaw Release -Checks` також запускає ті самі лінії QA Lab перед затвердженням релізу. +QA Lab має окремі лінії CI поза основним workflow з розумним визначенням охоплення. Workflow `Parity gate` запускається для відповідних змін у PR і через ручний запуск; він збирає приватне середовище виконання QA та порівнює імітаційні agentic-паки GPT-5.5 і Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі в `main` і через ручний запуск; він розпаралелює імітаційний parity gate, live-лінію Matrix і live-лінію Telegram як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а лінія Telegram використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі лінії QA Lab перед затвердженням релізу. -Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес для мейнтейнерів для -очищення дублікатів після злиття. За замовчуванням він працює в режимі dry-run і -закриває лише явно перелічені PR, коли `apply=true`. Перш ніж змінювати GitHub, -він перевіряє, що злитий PR справді змерджено, і що кожен дублікат має або спільну пов’язану issue, -або перекривні змінені hunks. +Workflow `Duplicate PRs After Merge` — це ручний workflow для супровідників для очищення дублікатів після приземлення змін. За замовчуванням він працює в режимі dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перш ніж змінювати стан у GitHub, він перевіряє, що приземлений PR змерджено і що кожен дублікат має або спільну згадану issue, або перетин змінених фрагментів. -Робочий процес `Docs Agent` — це керована подіями лінія обслуговування Codex для підтримки -наявної документації у відповідності до нещодавно злитих змін. У нього немає окремого розкладу: -його може запустити успішний запуск CI для push у `main`, виконаний не ботом, -а manual dispatch може запустити його безпосередньо. Виклики через workflow_run пропускаються, -якщо `main` уже пішла далі або якщо інший непропущений запуск Docs Agent був створений -протягом останньої години. Коли він запускається, він переглядає діапазон комітів від -попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один -щогодинний запуск може охопити всі зміни в main, накопичені з моменту останнього проходу документації. +Workflow `Docs Agent` — це керована подіями лінія супроводу Codex для підтримання наявної документації у відповідності до нещодавно приземлених змін. Він не має окремого розкладу: його може запустити успішний запуск CI для пушу в `main`, зроблений не ботом, а також його можна запустити вручну. Виклики через workflow run пропускаються, якщо `main` уже змінився або якщо інший непропущений запуск Docs Agent був створений протягом останньої години. Коли він запускається, він переглядає діапазон комітів від SHA джерела попереднього непропущеного Docs Agent до поточного `main`, тому один щогодинний запуск може охопити всі зміни в main, накопичені з часу останнього проходу документації. -Робочий процес `Test Performance Agent` — це керована подіями лінія обслуговування Codex -для повільних тестів. У нього немає окремого розкладу: його може запустити -успішний запуск CI для push у `main`, виконаний не ботом, але він пропускається, -якщо інший виклик через workflow_run уже виконався або виконується в той самий день UTC. -Manual dispatch обходить це денне обмеження активності. Лінія збирає згрупований звіт -про продуктивність Vitest для повного набору, дозволяє Codex вносити лише невеликі -виправлення продуктивності тестів без втрати покриття замість широких рефакторингів, -потім повторно запускає звіт для повного набору і відхиляє зміни, які зменшують -базову кількість тестів, що проходять. Якщо в базовому стані є тести, що падають, -Codex може виправляти лише очевидні збої, а звіт для повного набору після роботи агента -має бути успішним, перш ніж щось буде закомічено. Коли `main` просувається далі -до того, як bot push потрапляє в гілку, лінія перебазовує перевірений патч, -повторно запускає `pnpm check:changed` і повторює push; застарілі патчі з конфліктами пропускаються. -Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму -безпечну політику без sudo, що й агент документації. +Workflow `Test Performance Agent` — це керована подіями лінія супроводу Codex для повільних тестів. Він не має окремого розкладу: його може запустити успішний запуск CI для пушу в `main`, зроблений не ботом, але він пропускається, якщо інший виклик через workflow run уже виконувався або виконується того ж дня за UTC. Ручний запуск обходить це денне обмеження активності. Лінія створює згрупований звіт про продуктивність Vitest для повного набору тестів, дозволяє Codex робити лише невеликі виправлення продуктивності тестів без зниження покриття замість широких рефакторингів, потім повторно запускає звіт для повного набору тестів і відхиляє зміни, які зменшують кількість тестів, що проходять, у базовому стані. Якщо в базовому стані є тести, що не проходять, Codex може виправляти лише очевидні збої, а звіт після роботи агента для повного набору тестів має пройти, перш ніж щось буде закомічено. Коли `main` змінюється до того, як пуш бота буде приземлено, лінія перебазовує перевірений патч, повторно запускає `pnpm check:changed` і повторює спробу пушу; конфліктні застарілі патчі пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну політику drop-sudo, що й агент документації. ```bash gh workflow run duplicate-after-merge.yml \ @@ -65,74 +33,74 @@ gh workflow run duplicate-after-merge.yml \ ## Огляд завдань | Завдання | Призначення | Коли запускається | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ | -| `preflight` | Виявлення змін лише в документації, змінених областей, змінених розширень і побудова маніфесту CI | Завжди для push і PR, що не є draft | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory з npm | Завжди для push і PR, що не є draft | -| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR, що не є draft | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і повторно використовуваних downstream-артефактів | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | -| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні для Node | -| `checks-node-core-test` | Шарди основних Node-тестів, без урахування ліній каналів, bundled, контрактів і розширень | Зміни, релевантні для Node | -| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами розширень | -| `check` | Шардований еквівалент основного локального gate: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Шарди архітектури, меж, захисту поверхні розширень, меж пакетів і gateway-watch | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke-тест пам’яті під час запуску | Зміни, релевантні для Node | -| `checks` | Верифікатор для тестів каналів на зібраних артефактах плюс сумісність Node 22 лише для push | Зміни, релевантні для Node | -| `check-docs` | Перевірки форматування документації, lint і битих посилань | Документацію змінено | -| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні для Python Skills | -| `checks-windows` | Специфічні для Windows тестові лінії | Зміни, релевантні для Windows | -| `macos-node` | Лінія TypeScript-тестів на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | -| `macos-swift` | Лінтинг, збірка та тести Swift для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Модульні тести Android для обох flavor плюс одна збірка debug APK | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх main CI або manual dispatch | +| -------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------ | +| `preflight` | Визначає зміни лише в документації, змінені області охоплення, змінені розширення та будує маніфест CI | Завжди для push і PR, що не є draft | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft | +| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory npm | Завжди для push і PR, що не є draft | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR, що не є draft | +| `build-artifacts` | Збирає `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані артефакти для нижчих етапів | Зміни, релевантні Node | +| `checks-fast-core` | Швидкі лінії перевірки коректності в Linux, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні Node | +| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні Node | +| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні Node | +| `checks-node-core-test` | Шарди основних Node-тестів, без ліній каналів, bundled, контрактів і розширень | Зміни, релевантні Node | +| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами в розширеннях | +| `check` | Шардований еквівалент головного локального шлюзу: production types, lint, guard, test types і strict smoke | Зміни, релевантні Node | +| `check-additional` | Шарди архітектури, меж, guard для поверхні розширень, меж пакетів і gateway-watch | Зміни, релевантні Node | +| `build-smoke` | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску | Зміни, релевантні Node | +| `checks` | Верифікатор для тестів каналів зі зібраними артефактами плюс сумісність Node 22 лише для push | Зміни, релевантні Node | +| `check-docs` | Форматування документації, lint і перевірки зламаних посилань | Змінено документацію | +| `skills-python` | Ruff + pytest для Skills на Python | Зміни, релевантні Skills на Python | +| `checks-windows` | Специфічні для Windows лінії тестування | Зміни, релевантні Windows | +| `macos-node` | Лінія тестів TypeScript для macOS з використанням спільних зібраних артефактів | Зміни, релевантні macOS | +| `macos-swift` | Lint, збірка і тести Swift для застосунку macOS | Зміни, релевантні macOS | +| `android` | Модульні тести Android для обох варіантів плюс одна збірка debug APK | Зміни, релевантні Android | +| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успішний main CI або ручний запуск | ## Порядок 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`, лише для PR `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих матричних завдань для артефактів і платформ. +3. `build-artifacts` виконується паралельно зі швидкими Linux-лініями, щоб нижчі етапи могли почати роботу, щойно спільна збірка буде готова. +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` і покривається модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Зміни workflow CI перевіряють граф Node CI та linting workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні лінії й надалі обмежуються змінами у вихідному коді відповідних платформ. -Зміни лише в маршрутизації CI, окремі вибрані дешеві правки фікстур core-test, а також вузькі правки helper/test-routing для контрактів plugin використовують швидкий шлях маніфесту лише для Node: preflight, security і єдине завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності Node 22, контрактів каналів, повних шард core, шардів bundled-plugin і додаткових матриць guard, коли змінені файли обмежені лише поверхнями маршрутизації або helper, які швидке завдання перевіряє безпосередньо. -Windows Node-перевірки обмежені Windows-специфічними обгортками process/path, helper для npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цю лінію; нерелевантні зміни у вихідному коді, plugin, install-smoke і зміни лише в тестах залишаються в Linux Node-лініях, щоб не займати Windows worker на 16 vCPU для покриття, яке вже перевіряється звичайними тестовими shards. -Окремий workflow `install-smoke` повторно використовує той самий скрипт областей змін через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull request запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin і поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke-завдання. Зміни лише у вихідному коді bundled plugin, зміни лише в тестах і зміни лише в документації не займають Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg для bundled extension і запускає обмежений Docker profile bundled-plugin із загальним timeout команди 240 секунд, де `docker run` для кожного сценарію обмежений окремо. Повний шлях зберігає покриття встановлення QR package і installer Docker/update для нічних запланованих запусків, manual dispatch, перевірок релізу через workflow-call і pull request, які справді зачіпають поверхні installer/package/Docker. Push у `main`, включно з merge commit, не примушують запускати повний шлях; коли логіка changed-scope запросила б повне покриття для push, workflow залишає швидкий Docker smoke, а повний install smoke відкладає до нічної або релізної перевірки. Повільний smoke image-provider для глобального встановлення Bun окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а manual dispatch `install-smoke` може його явно ввімкнути, але pull request і push у `main` його не запускають. QR і installer Docker-тести зберігають власні Dockerfile, орієнтовані на встановлення. Локальний `test:docker:all` попередньо збирає один спільний образ live-test і один спільний образ built-app з `scripts/e2e/Dockerfile`, а потім запускає smoke-лінії live/E2E із weighted scheduler та `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до provider, також 10 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких ліній за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб лінії npm install і multi-service не перевантажували Docker, поки легші лінії все ще заповнюють доступні слоти. Запуски ліній за замовчуванням зміщені на 2 секунди, щоб уникати локальних бур створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегований запуск попередньо перевіряє Docker, видаляє застарілі контейнери OpenClaw E2E, виводить стан активних ліній, зберігає тривалості ліній для впорядкування за принципом longest-first і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для аналізу scheduler. Він за замовчуванням перестає планувати нові pooled-лінії після першої помилки, а кожна лінія має резервний timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; окремі live/tail-лінії використовують жорсткіші обмеження для конкретної лінії. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні лінії scheduler, включно з лініями лише для релізів, такими як `install-e2e`, і розділеними лініями bundled update, такими як `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб агенти могли відтворити одну проблемну лінію. Повторно використовуваний workflow live/E2E збирає і публікує один SHA-tagged Docker E2E-образ у GHCR, а потім запускає Docker-набір релізного шляху максимум у трьох chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk один раз витягував спільний образ і виконував кілька ліній через той самий weighted scheduler (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=core|package-update|plugins-integrations`). Кожен chunk вивантажує `.artifacts/docker-tests/` із логами ліній, тривалостями, `summary.json` і командами повторного запуску для кожної лінії. Вхід `docker_lanes` workflow запускає вибрані лінії на підготовленому образі замість трьох chunk jobs, що обмежує налагодження проблемної лінії одним цільовим Docker job; якщо вибрана лінія є live Docker-лінією, цільове завдання локально збирає образ live-test для цього повторного запуску. Коли Open WebUI запитується разом із набором release-path, він запускається всередині chunk plugins/integrations замість резервування четвертого Docker worker; Open WebUI зберігає окреме standalone job лише для dispatch типу openwebui-only. Запланований workflow live/E2E щодня запускає повний Docker-набір release-path. Матриця bundled update розділена за ціллю оновлення, щоб повторювані проходи npm update і doctor repair могли шардуватися разом з іншими bundled-перевірками. +Логіка охоплення міститься в `scripts/ci-changed-scope.mjs` і покривається модульними тестами в `src/scripts/ci-changed-scope.test.ts`. +Зміни workflow CI перевіряють граф Node CI разом із lint для workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні лінії й надалі прив’язані до змін у вихідному коді відповідних платформ. +Зміни лише в маршрутизації CI, окремі дешеві правки фікстур core-тестів і вузькі правки helper/test-routing для контрактів плагінів використовують швидкий шлях маніфесту лише для Node: preflight, security і єдине завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності з Node 22, контрактів каналів, повних shard-ів core, shard-ів bundled-plugin і додаткових матриць guard, коли змінені файли обмежуються поверхнями маршрутизації або helper, які швидке завдання перевіряє безпосередньо. +Перевірки Windows Node прив’язані до специфічних для Windows обгорток process/path, helper для npm/pnpm/UI runner, конфігурації package manager і поверхонь workflow CI, що запускають цю лінію; не пов’язані зміни у вихідному коді, плагінах, install-smoke і лише в тестах залишаються на Linux Node лініях, щоб не резервувати Windows worker на 16 vCPU для покриття, яке вже перевіряється звичайними test shard-ами. +Окремий workflow `install-smoke` повторно використовує той самий скрипт визначення охоплення через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Для pull request запускається швидкий шлях для поверхонь Docker/package, змін пакетів/маніфестів bundled plugin і поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише у вихідному коді bundled plugin, лише в тестах і лише в документації не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає smoke CLI `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker profile bundled-plugin із сукупним таймаутом команди 240 секунд, де кожен сценарій `docker run` має власне окреме обмеження. Повний шлях зберігає покриття встановлення QR package і installer Docker/update для нічних запланованих запусків, ручних запусків, workflow-call перевірок релізу і pull request, які справді зачіпають поверхні installer/package/Docker. Пуші в `main`, включно з merge commit, не примушують повний шлях; коли логіка changed-scope на пуші вимагала б повне покриття, workflow залишає швидкий Docker smoke, а повний install smoke переносить на нічну або релізну перевірку. Повільний smoke для Bun global install image-provider окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `install-smoke` можуть явно ввімкнути його, але pull request і пуші в `main` його не запускають. Тести QR і installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Локальний `test:docker:all` попередньо збирає один спільний live-test образ і два спільні built-app образи `scripts/e2e/Dockerfile`: bare image для ліній installer/update/plugin-dependency і functional image, який попередньо готує runtime dependency для bundled plugin для звичайних функціональних ліній. Планувальник вибирає образ для лінії через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте типову кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до провайдера, 10 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження для важких ліній за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=6`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=8` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб лінії npm install і multi-service не перевантажували Docker, поки легші лінії все ще заповнюють доступні слоти. Запуски ліній за замовчуванням зсуваються на 2 секунди, щоб уникати локальних сплесків створення контейнерів Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегат попередньо перевіряє Docker, видаляє застарілі контейнери OpenClaw E2E, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших до найкоротших і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для інспекції планувальника. За замовчуванням він припиняє планувати нові pooled lanes після першої помилки, і кожна лінія має резервний таймаут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; окремі live/tail лінії використовують жорсткіші індивідуальні обмеження. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні лінії планувальника, включно з лініями лише для релізу, такими як `install-e2e`, і розділеними лініями оновлення bundled, такими як `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб агенти могли відтворити одну збійну лінію. Повторно використовуваний live/E2E workflow збирає і пушить один bare GHCR Docker E2E image з тегом SHA і один functional GHCR Docker E2E image з тегом SHA, а потім запускає релізний Docker suite не більш ніж у трьох chunked jobs із `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk міг витягнути потрібний тип образу й виконати кілька ліній через той самий ваговий планувальник (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=core|package-update|plugins-integrations`). Кожен chunk завантажує `.artifacts/docker-tests/` із логами ліній, таймінгами, `summary.json`, таймінгами фаз і командами повторного запуску для кожної лінії. Вхід `docker_lanes` workflow запускає вибрані лінії проти підготовлених образів замість трьох chunk jobs, що обмежує налагодження збійної лінії одним цільовим Docker job; якщо вибрана лінія є live Docker lane, цільове завдання локально збирає live-test image для такого повторного запуску. Коли Open WebUI запитується разом із релізним suite, він виконується всередині chunk plugins/integrations замість резервування четвертого Docker worker; Open WebUI зберігає окреме standalone job лише для запусків openwebui-only. Запланований live/E2E workflow щодня запускає повний релізний Docker suite. Матриця bundled update розділена за ціллю оновлення, щоб повторні проходи npm update і doctor repair могли shard-итися разом з іншими bundled-перевірками. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний gate суворіший щодо архітектурних меж, ніж широкий платформний scope у CI: зміни в production core запускають typecheck production core плюс тести core, зміни лише в тестах core запускають лише typecheck/tests для тестів core, зміни в production extension запускають typecheck production extension плюс тести extension, а зміни лише в тестах extension запускають лише typecheck/tests для тестів extension. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку до extension, бо extensions залежать від цих core-контрактів. Version bump лише в метаданих релізу запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно переводять у всі лінії. +Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо меж архітектури, ніж широке платформне охоплення CI: зміни у production core запускають typecheck production core плюс core-тести, зміни лише в core-тестах запускають лише typecheck/tests для core-тестів, зміни у production розширень запускають typecheck production розширень плюс тести розширень, а зміни лише в тестах розширень запускають лише typecheck/tests для тестів розширень. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на розширення, оскільки розширення залежать від цих core-контрактів. Зміни лише в метаданих релізу з підвищенням версії запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config для безпеки переводять перевірку на всі лінії. -Для push матриця `checks` додає лінію лише для push — `compat-node22`. Для pull request ця лінія пропускається, і матриця зосереджується на звичайних тестових/канальних лініях. +На пушах матриця `checks` додає лінію `compat-node22`, яка запускається лише для push. Для pull request цю лінію пропускають, і матриця залишається зосередженою на звичайних test/channel лініях. -Найповільніші сімейства Node-тестів розділено або збалансовано так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: контракти каналів виконуються як три weighted shards, тести bundled plugin балансуються між шістьма workers для extensions, невеликі core unit-лінії об’єднуються в пари, auto-reply запускається на чотирьох збалансованих workers із піддеревом reply, розділеним на shards agent-runner, dispatch і commands/state-routing, а конфігурації agentic gateway/plugin розподіляються між наявними Node-завданнями agentic лише для вихідного коду замість очікування на built artifacts. Широкі browser-, QA-, media- і miscellaneous plugin-тести використовують свої окремі конфігурації Vitest замість спільної універсальної конфігурації plugin. Завдання shard для extensions запускають до двох груп конфігурацій plugin одночасно з одним worker Vitest на групу та більшим heap Node, щоб великі пакети plugin з важкими import не створювали додаткових завдань CI. Широка лінія agents використовує спільний file-parallel scheduler Vitest, бо в ній домінують import/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із shard infra core-runtime, щоб спільний runtime-shard не утримував tail. Шарди за include-pattern записують записи часу з використанням імені CI-shard, тому `.artifacts/vitest-shard-timings.json` може відрізняти цілу конфігурацію від відфільтрованого shard. `check-additional` тримає compile/canary-роботи package-boundary разом і відокремлює архітектуру runtime topology від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guards паралельно в межах одного завдання. Gateway watch, channel-тести та shard support-boundary core запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано, зберігаючи свої старі назви перевірок як lightweight verifier jobs і водночас уникаючи двох додаткових Blacksmith workers і другої черги споживачів артефактів. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Flavor third-party не має окремого source set або manifest; його лінія модульних тестів усе одно компілює цей flavor з прапорцями BuildConfig для SMS/call-log, уникаючи при цьому дублювання завдання пакування debug APK на кожному Android-релевантному push. -`extension-fast` є лише для PR, бо push-запуски вже виконують повні shards bundled plugin. Це зберігає швидкий зворотний зв’язок для змінених plugin під час рев’ю без резервування додаткового Blacksmith worker у `main` для покриття, яке вже присутнє в `checks-node-extensions`. +Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: контракти каналів працюють як три зважені shard-и, тести bundled plugin балансуються між шістьма worker-ами розширень, малі core unit lanes поєднуються в пари, auto-reply запускається на чотирьох збалансованих worker-ах із розділенням reply subtree на shard-и agent-runner, dispatch і commands/state-routing, а конфігурації agentic gateway/plugin розподіляються між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media та miscellaneous plugin-тести використовують свої окремі конфігурації Vitest замість спільного plugin catch-all. Завдання shard-ів розширень запускають до двох груп конфігурацій плагінів одночасно з одним worker-ом Vitest на групу та більшим heap Node, щоб пакетні набори плагінів із великим імпортом не створювали зайвих CI jobs. Широка лінія agents використовує спільний file-parallel scheduler Vitest, оскільки в ній домінують імпорт і планування, а не один повільний тестовий файл. `runtime-config` виконується разом із shard-ом infra core-runtime, щоб спільний runtime shard не ставав найдовшим. Shard-и за include pattern записують таймінги з використанням імені CI shard, тому `.artifacts/vitest-shard-timings.json` може розрізняти цілу конфігурацію й відфільтрований shard. `check-additional` тримає разом роботу package-boundary compile/canary і відокремлює runtime topology architecture від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guard паралельно всередині одного job. Gateway watch, channel-тести та shard core support-boundary виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі назви перевірок як полегшені verifier jobs, водночас уникаючи двох додаткових Blacksmith worker-ів і другої черги споживачів артефактів. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Варіант third-party не має окремого source set або manifest; його лінія unit-тестів усе одно компілює цей варіант із прапорцями SMS/call-log у BuildConfig, водночас уникаючи дублювання packaging job для debug APK на кожному Android-релевантному push. +`extension-fast` запускається лише для PR, тому що push-запуски вже виконують повні shard-и bundled plugin. Це дає швидкий зворотний зв’язок щодо змінених плагінів під час review без резервування додаткового Blacksmith worker-а в `main` для покриття, яке вже присутнє в `checks-node-extensions`. -GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо тільки найновіший запуск для того самого ref також не завершується з помилкою. Агреговані shard-перевірки використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні збої shard, але не стають у чергу після того, як увесь workflow уже був замінений новішим. -Ключ concurrency у CI має версію (`CI-v7-*`), щоб zombie-елемент на боці GitHub у старій групі черги не міг безкінечно блокувати новіші запуски для main. +GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується збоєм. Агреговані shard-перевірки використовують `!cancelled() && always()`, щоб вони все одно повідомляли про звичайні збої shard-ів, але не ставали в чергу після того, як увесь workflow уже був замінений. +Ключ конкурентності CI версіонований (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безкінечно блокувати новіші запуски main. ## Runner-и -| Runner | Завдання | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, shards `check`, окрім lint, shards і агрегати `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shards Linux Node-тестів, shards тестів bundled plugin, `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`; forks повертаються до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; forks повертаються до `macos-latest` | +| Runner | Завдання | +| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, shard-и `check`, крім lint, shard-и й агрегати `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла раніше ставати в чергу | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shard-и Linux Node-тестів, shard-и тестів bundled plugin, `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 # розумний локальний gate: changed typecheck/lint/tests за boundary lane -pnpm check # швидкий локальний gate: production tsgo + sharded lint + parallel fast guards +pnpm check:changed # розумний локальний шлюз: changed typecheck/lint/tests за boundary lane +pnpm check # швидкий локальний шлюз: production tsgo + шардований lint + паралельні fast guard pnpm check:test-types -pnpm check:timed # той самий gate з таймінгами для кожного етапу +pnpm check:timed # той самий шлюз із таймінгами для кожного етапу pnpm build:strict-smoke pnpm check:architecture pnpm test:gateway:watch-regression @@ -140,12 +108,12 @@ pnpm test # тести vitest pnpm test:channels pnpm test:contracts:channels pnpm check:docs # форматування документації + lint + биті посилання -pnpm build # збірка dist, коли важливі лінії CI artifact/build-smoke -pnpm ci:timings # підсумувати останній запуск push CI для origin/main -pnpm ci:timings:recent # порівняти нещодавні успішні запуски main CI -node scripts/ci-run-timings.mjs # підсумувати загальний час, час у черзі та найповільніші завдання -node scripts/ci-run-timings.mjs --latest-main # ігнорувати issue/comment noise і вибрати push CI для origin/main -node scripts/ci-run-timings.mjs --recent 10 # порівняти нещодавні успішні запуски main CI +pnpm build # зібрати dist, коли мають значення лінії CI artifact/build-smoke +pnpm ci:timings # зведення для останнього CI-запуску push у origin/main +pnpm ci:timings:recent # порівняти нещодавні успішні CI-запуски main +node scripts/ci-run-timings.mjs # зведення загального часу, часу очікування в черзі та найповільніших завдань +node scripts/ci-run-timings.mjs --latest-main # ігнорувати шум від issue/comment і вибрати push CI для origin/main +node scripts/ci-run-timings.mjs --recent 10 # порівняти нещодавні успішні CI-запуски main pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json ``` diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index 9e893339f..f6f248f16 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -4,51 +4,51 @@ read_when: summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage title: Тести x-i18n: - generated_at: "2026-04-26T09:31:48Z" + generated_at: "2026-04-26T21:58:20Z" model: gpt-5.4 provider: openai - source_hash: 24eb2d122c806237bd4b90dffbd293479763c11a42cfcd195e1aed59efc71a5b + source_hash: cc575df6f7a6edd72fe5db766b140587e16c2daf887bb3ce3f9d273a0e7cf311 source_path: reference/test.md workflow: 15 --- - Повний набір для тестування (сьюти, 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 coverage, замість того щоб вважати всі файли вихідного коду в розділених lane непокритими. -- `pnpm test:coverage:changed`: запускає unit coverage лише для файлів, змінених відносно `origin/main`. -- `pnpm test:changed`: розгортає змінені git-шляхи в scoped lane Vitest, коли diff зачіпає лише маршрутизовані файли source/test. Зміни config/setup, як і раніше, повертаються до нативного запуску кореневих project, щоб зміни wiring за потреби повторно запускали ширший набір. -- `pnpm test:changed:focused`: запуск змінених тестів для внутрішнього циклу розробки. Запускає лише точні цілі на основі прямих змін у тестах, сусідніх файлів `*.test.ts`, явних зіставлень source та локального графа імпортів. Широкі зміни config/package пропускаються замість розгортання до повного резервного запуску changed-test. -- `pnpm changed:lanes`: показує архітектурні lane, які запускаються diff відносно `origin/main`. -- `pnpm check:changed`: запускає розумну changed-перевірку для diff відносно `origin/main`. Вона запускає core-роботи з lane core tests, роботу extension — з lane extension tests, зміни лише в тестах — лише з typecheck/tests для тестів, розгортає зміни публічного Plugin SDK або plugin-contract до одного проходу валідації extension і залишає підвищення версій лише в metadata release на цільових перевірках version/config/root-dependency. -- `pnpm test`: маршрутизує явні цілі file/directory через scoped lane Vitest. Запуски без цілей використовують фіксовані shard-групи й розгортаються до leaf config для локального паралельного виконання; група extension завжди розгортається до shard config кожного extension окремо, а не до одного великого кореневого process. -- Повні запуски shard, shard extension і shard за include-pattern оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; наступні запуски всього config використовують ці таймінги для балансування повільних і швидких shard. CI-shard за include-pattern додають ім’я shard до ключа таймінгу, що дозволяє зберігати таймінги відфільтрованих shard без заміни даних таймінгів для всього config. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів. -- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через виділені легкі lane, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі сценарії на їхніх наявних lane. -- Файли source із сусідніми тестами зіставляються спочатку з цими сусідніми тестами, перш ніж переходити до ширших glob-шаблонів каталогу. Зміни helper у `test/helpers/channels` і `test/helpers/plugins` використовують локальний граф імпортів, щоб запускати тести, які їх імпортують, замість широкого запуску кожного shard, коли шлях залежності є точним. -- `auto-reply` тепер також розбито на три виділені config (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper. -- Базовий config Vitest тепер за замовчуванням використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх config репозиторію. +- `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-тестів із покриттям, замість того щоб вважати всі вихідні файли split-lane непокритими. +- `pnpm test:coverage:changed`: запускає unit-покриття лише для файлів, змінених відносно `origin/main`. +- `pnpm test:changed`: розгортає змінені шляхи git у відповідні маршрутизовані lane-и Vitest, коли diff торкається лише маршрутизованих вихідних/тестових файлів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску root projects, щоб зміни в wiring перевірялися ширше, коли це потрібно. +- `pnpm test:changed:focused`: запуск змінених тестів для внутрішнього циклу розробки. Він запускає лише точні цілі з прямих змін тестів, сусідніх файлів `*.test.ts`, явних мапінгів вихідних файлів і локального графа імпортів. Широкі зміни/config/package пропускаються замість розгортання до повного резервного запуску changed-test. +- `pnpm changed:lanes`: показує архітектурні lane-и, активовані diff відносно `origin/main`. +- `pnpm check:changed`: запускає розумну перевірку changed gate для diff відносно `origin/main`. Вона запускає core-роботи разом із core test lanes, роботу extension — разом із extension test lanes, зміни лише в тестах — лише з test typecheck/tests, розгортає зміни публічного Plugin SDK або plugin-contract до одного проходу валідації extension, а також залишає version bumps лише в release metadata на цільових перевірках version/config/root-dependency. +- `pnpm test`: маршрутизує явні цілі файлів/каталогів через відповідні lane-и Vitest. Запуски без цілей використовують фіксовані групи shard-ів і розгортаються до leaf configs для локального паралельного виконання; група extension завжди розгортається до конфігурацій shard-ів окремих extension, а не до одного гігантського процесу root-project. +- Повні запуски, запуски extension і запуски shard-ів за include-pattern оновлюють локальні дані часу виконання в `.artifacts/vitest-shard-timings.json`; наступні запуски всієї конфігурації використовують ці дані, щоб збалансувати повільні та швидкі shard-и. CI-shard-и за include-pattern додають ім’я shard-а до ключа часу, що дозволяє зберігати видимість часу відфільтрованих shard-ів, не замінюючи дані часу всієї конфігурації. Встановіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт часу. +- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane-и, які залишають лише `test/setup.ts`, а сценарії з важким runtime залишаються на наявних lane-ах. +- Вихідні файли із сусідніми тестами спочатку мапляться на цей сусідній тест, а вже потім переходять до ширших glob-шаблонів каталогів. Зміни helper-ів у `test/helpers/channels` і `test/helpers/plugins` використовують локальний граф імпортів, щоб запускати тести, які їх імпортують, замість широкого запуску кожного shard-а, коли шлях залежності точний. +- `auto-reply` тепер також поділяється на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими тестами status/token/helper верхнього рівня. +- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх конфігураціях репозиторію. - `pnpm test:channels` запускає `vitest.channels.config.ts`. -- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel plugins, browser plugin і OpenAI запускаються як виділені shard; інші групи plugin залишаються згрупованими. Використовуйте `pnpm test extensions/` для одного bundled lane plugin. -- `pnpm test:perf:imports`: вмикає звітування Vitest про тривалість імпортів і їх розбивку, при цьому все ще використовує маршрутизацію scoped lane для явних цілей file/directory. -- `pnpm test:perf:imports:changed`: той самий профайлінг імпортів, але лише для файлів, змінених відносно `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` вимірює продуктивність маршрутизованого шляху changed-mode порівняно з нативним запуском кореневих 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`). -- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожен leaf config Vitest із повного набору й записує згруповані дані про тривалість разом з JSON/log-артефактами для кожного config. Агент Test Performance використовує це як базову лінію перед спробами виправити повільні тести. -- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після змін, орієнтованих на продуктивність. +- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard-и extension/plugin. Важкі channel plugins, browser plugin і OpenAI запускаються як окремі shard-и; інші групи plugin залишаються згрупованими. Використовуйте `pnpm test extensions/` для одного lane-а зібраного plugin. +- `pnpm test:perf:imports`: вмикає звітність Vitest про тривалість імпорту та import-breakdown, водночас і далі використовуючи маршрутизацію відповідних lane-ів для явних цілей файлів/каталогів. +- `pnpm test:perf:imports:changed`: той самий import profiling, але лише для файлів, змінених відносно `origin/main`. +- `pnpm test:perf:changed:bench -- --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`). +- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожну leaf config Vitest повного набору і записує згруповані дані тривалості разом з JSON/log-артефактами для кожної конфігурації. Агент продуктивності тестів використовує це як базову лінію перед спробами виправлення повільних тестів. +- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після зміни, орієнтованої на продуктивність. - Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. -- `pnpm test:e2e`: запускає smoke-тести gateway end-to-end (спарювання кількох екземплярів WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю worker у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=`, а для докладних логів установіть `OPENCLAW_E2E_VERBOSE=1`. -- `pnpm test:live`: запускає live-тести provider (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для provider `*_LIVE_TEST=1`), щоб зняти пропуск. -- `pnpm test:docker:all`: один раз збирає спільний образ для live-тестів і образ Docker E2E, а потім запускає Docker smoke lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` через зважений планувальник. `OPENCLAW_DOCKER_ALL_PARALLELISM=` керує кількістю слотів process і за замовчуванням дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` керує tail pool, чутливим до provider, і також за замовчуванням дорівнює 10. Обмеження для важких lane за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; обмеження для provider за замовчуванням допускають один важкий lane на provider через `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` і `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Для більших хостів використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`. Запуск lane за замовчуванням зміщується на 2 секунди, щоб уникнути локальних штормів створення Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=`. Runner за замовчуванням виконує попередню перевірку Docker, очищає застарілі контейнери OpenClaw E2E, кожні 30 секунд виводить статус активних lane, спільно використовує кеші інструментів CLI provider між сумісними lane, один раз за замовчуванням повторює тимчасові збої live-provider (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=`) і зберігає таймінги lane у `.artifacts/docker-tests/lane-timings.json` для впорядкування за принципом longest-first у наступних запусках. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести manifest lane без запуску Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=` для налаштування виведення статусу або `OPENCLAW_DOCKER_ALL_TIMINGS=0` для вимкнення повторного використання таймінгів. Використовуйте `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` для лише детермінованих/локальних lane або `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` лише для lane live-provider; псевдоніми package: `pnpm test:docker:local:all` і `pnpm test:docker:live:all`. Режим лише live об’єднує основні та tail live lane в один pool longest-first, щоб кошики provider могли разом пакувати роботу Claude, Codex і Gemini. Runner припиняє планування нових pooled lane після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожен lane має резервний timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lane використовують жорсткіші обмеження для кожного lane. Команди налаштування Docker для CLI backend мають власний timeout через `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (за замовчуванням 180). Логи для кожного lane записуються в `.artifacts/docker-tests//`. -- `pnpm test:docker:browser-cdp-snapshot`: збирає E2E-контейнер source на базі Chromium, запускає raw CDP і ізольований Gateway, виконує `browser doctor --deep` і перевіряє, що CDP role snapshot містять URL посилань, clickables, підвищені курсором, iframe refs і метадані frame. -- Live Docker probes для CLI backend можна запускати як фокусні lane, наприклад `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` або `pnpm test:docker:live-cli-backend:codex:mcp`. Для Claude і Gemini є відповідні псевдоніми `:resume` і `:mcp`. -- `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`: запускає seed-контейнер Gateway і другий клієнтський контейнер, який піднімає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані attachment, поведінку черги live event, маршрутизацію outbound send і сповіщення про channel + permission у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP frame безпосередньо, щоб smoke відображав те, що міст реально надсилає. +- `pnpm test:e2e`: запускає наскрізні smoke-тести Gateway (multi-instance WS/HTTP/node pairing). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=`, а для докладних логів встановіть `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 lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1` через зважений планувальник. Базовий образ (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) використовується для lane-ів installer/update/plugin-dependency; функціональний образ (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) заздалегідь готує залежності runtime для bundled plugin для звичайних lane-ів функціональності. `OPENCLAW_DOCKER_ALL_PARALLELISM=` керує кількістю слотів процесів і за замовчуванням дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` керує чутливим до провайдерів tail pool і за замовчуванням також дорівнює 10. Обмеження для важких lane-ів за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; обмеження провайдерів за замовчуванням — один важкий lane на провайдера через `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` і `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Для більших хостів використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`. Запуски lane-ів за замовчуванням відтерміновуються на 2 секунди, щоб уникати локальних сплесків створення контейнерів демоном Docker; змінити це можна через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=`. Runner за замовчуванням виконує попередню перевірку Docker, очищує застарілі контейнери OpenClaw E2E, кожні 30 секунд виводить статус активних lane-ів, спільно використовує кеші CLI-інструментів провайдерів між сумісними lane-ами, за замовчуванням один раз повторює тимчасові збої live-провайдерів (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=`) і зберігає час виконання lane-ів у `.artifacts/docker-tests/lane-timings.json` для впорядкування від найдовших до найкоротших у наступних запусках. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести маніфест lane-ів без запуску Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=` для налаштування інтервалу статусу або `OPENCLAW_DOCKER_ALL_TIMINGS=0` для вимкнення повторного використання даних часу. Використовуйте `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` лише для детермінованих/локальних lane-ів або `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` лише для lane-ів live-провайдерів; package aliases — `pnpm test:docker:local:all` і `pnpm test:docker:live:all`. У режимі лише live основні та tail live lane-и об’єднуються в один пул із пріоритетом найдовших, щоб кошики провайдерів могли спільно пакувати навантаження Claude, Codex і Gemini. Runner припиняє планувати нові pooled lane-и після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожен lane має резервний timeout 120 хвилин, який можна змінити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; для деяких live/tail lane-ів використовуються жорсткіші обмеження на рівні lane-а. Команди налаштування Docker для CLI backend мають окремий timeout через `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (за замовчуванням 180). Логи кожного lane-а та часи фаз `summary.json` записуються в `.artifacts/docker-tests//`. +- `pnpm test:docker:browser-cdp-snapshot`: збирає вихідний E2E-контейнер на базі Chromium, запускає raw CDP разом з ізольованим Gateway, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots містять URL-посилань, clickables, підняті курсором, iframe refs і метадані frame. +- Live Docker probes для CLI backend можна запускати як цільові lane-и, наприклад `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` або `pnpm test:docker:live-cli-backend:codex:mcp`. Для Claude і Gemini є відповідні aliases `:resume` і `:mcp`. +- `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`: запускає seeded-контейнер Gateway і другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє routed conversation discovery, читання transcript, метадані вкладень, поведінку live event queue, маршрутизацію outbound send, а також сповіщення про channel + permissions у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає необроблені stdio MCP frames безпосередньо, щоб smoke-тест відображав те, що міст реально надсилає. -## Локальна PR-перевірка +## Локальна перевірка PR -Для локальних перевірок перед злиттям PR/проходження gate виконайте: +Для локальних перевірок land/gate PR виконайте: - `pnpm check:changed` - `pnpm check` @@ -57,12 +57,12 @@ x-i18n: - `pnpm test` - `pnpm check:docs` -Якщо `pnpm test` дає flaky-результат на завантаженому хості, повторіть запуск один раз, перш ніж вважати це регресією, а потім ізолюйте проблему через `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: +Якщо `pnpm test` дає flaky-результат на завантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test` - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed` -## Бенч затримки model (локальні ключі) +## Бенчмарк затримки моделі (локальні ключі) Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts) @@ -70,14 +70,14 @@ x-i18n: - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10` - Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY` -- Промпт за замовчуванням: “Відповідай одним словом: ok. Без розділових знаків або додаткового тексту.” +- Стандартний prompt: “Reply with a single word: ok. No punctuation or extra text.” Останній запуск (2025-12-31, 20 запусків): - minimax median 1279ms (min 1114, max 2431) - opus median 2454ms (min 1224, max 3170) -## Бенч запуску CLI +## Бенчмарк запуску CLI Скрипт: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts) @@ -98,21 +98,21 @@ 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-и: - `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`: обидва пресети +- `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: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` +- `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 у репозиторії: +Закомічений fixture: - `test/fixtures/cli-startup-bench.json` - Оновити через `pnpm test:startup:bench:update` @@ -120,19 +120,19 @@ Fixture у репозиторії: ## Onboarding E2E (Docker) -Docker є необов’язковим; це потрібно лише для containerized smoke-тестів onboarding. +Docker є необов’язковим; це потрібно лише для контейнеризованих smoke-тестів onboarding. -Повний cold-start потік у чистому Linux-контейнері: +Повний cold-start flow у чистому Linux-контейнері: ```bash scripts/e2e/onboard-docker.sh ``` -Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`. +Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, потім запускає Gateway і виконує `openclaw health`. -## QR import smoke (Docker) +## Smoke-тест імпорту QR (Docker) -Гарантує, що підтримуваний helper QR runtime завантажується в підтримуваних Docker runtime Node (Node 24 за замовчуванням, Node 22 сумісний): +Гарантує, що підтримуваний helper runtime для QR завантажується в підтримуваних Node runtime Docker (Node 24 за замовчуванням, Node 22 сумісний): ```bash pnpm test:docker:qr