From f7ea0e06be676e73e085c202846f2992d4e7ece9 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Fri, 24 Apr 2026 22:54:40 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/ci.md | 174 +++---- docs/uk/help/testing.md | 722 ++++++++++++++-------------- docs/uk/providers/github-copilot.md | 120 +++-- docs/uk/reference/test.md | 96 ++-- 4 files changed, 550 insertions(+), 562 deletions(-) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 9079e7217..423d69e81 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,60 +1,60 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося. - - Ви налагоджуєте збої в перевірках GitHub Actions. + - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Ви налагоджуєте збої в перевірках GitHub Actions summary: Граф завдань CI, межі перевірок і локальні еквіваленти команд title: конвеєр CI x-i18n: - generated_at: "2026-04-24T19:51:03Z" + generated_at: "2026-04-24T22:51:37Z" model: gpt-5.4 provider: openai - source_hash: 8407768803b8d92e03a7fb453307a64cb4f2342ba3894b51d4c928dd434fede6 + source_hash: bfcd687e6555b15ddebe3c061a814911d4f8a49c0db1c42aff357976a82bbbd5 source_path: ci.md workflow: 15 --- -CI запускається для кожного push до `main` і кожного pull request. Він використовує розумне визначення меж, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки. +CI запускається для кожного push до `main` і для кожного pull request. Він використовує розумне визначення області змін, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки. -QA Lab має виділені смуги CI поза межами основного workflow з розумним визначенням меж. Workflow -`Parity gate` запускається для відповідних змін у PR і через ручний dispatch; він -збирає приватний runtime QA і порівнює agentic-паки mock GPT-5.4 та Opus 4.6. +QA Lab має окремі смуги CI поза основним workflow з розумним визначенням області змін. Workflow +`Parity gate` запускається для відповідних змін у PR і через ручний запуск; він +збирає приватне середовище виконання QA та порівнює agentic pack-и mock GPT-5.4 і Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через -ручний dispatch; він розгалужує mock parity gate, live Matrix lane і live -Telegram lane як паралельні завдання. Live-завдання використовують environment `qa-live-shared`, -а смуга Telegram використовує оренди Convex. `OpenClaw Release +ручний запуск; він розгалужує mock parity gate, live Matrix lane і live +Telegram lane як паралельні завдання. Live-завдання використовують середовище +`qa-live-shared`, а Telegram lane використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі смуги QA Lab перед погодженням релізу. Workflow `Duplicate PRs After Merge` — це ручний workflow для мейнтейнерів для очищення дублікатів після злиття. За замовчуванням він працює в режимі dry-run і -закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub -він перевіряє, що злитий PR має статус merged, і що кожен дублікат має або -спільну згадану issue, або перекривні змінені hunks. +закриває лише явно перелічені PR, коли `apply=true`. Перед внесенням змін у GitHub +він перевіряє, що злитий PR справді об’єднано, і що кожен дублікат має або спільну +пов’язану issue, або перетин змінених фрагментів. -Workflow `Docs Agent` — це event-driven смуга технічного обслуговування Codex для підтримання -наявної документації у відповідності до нещодавно злитих змін. У нього немає окремого запуску за розкладом: -його може запустити успішний неботовий CI run push до `main`, а -ручний dispatch може запустити його напряму. Виклики через workflow-run пропускаються, -якщо `main` уже пішов далі або якщо інший непропущений запуск Docs Agent -було створено протягом останньої години. Коли він запускається, він -переглядає діапазон комітів від SHA джерела попереднього непропущеного Docs Agent до -поточного `main`, тож один щогодинний запуск може охопити всі зміни в main, -накопичені з часу останнього проходу документації. +Workflow `Docs Agent` — це maintenance lane Codex на основі подій для підтримання +наявної документації у відповідності до нещодавно злитих змін. Він не має окремого запуску за розкладом: +його може запустити успішний CI run не-бота для push у `main`, а також він може +запускатися безпосередньо вручну. Запуски через workflow-run пропускаються, якщо +`main` уже пішов уперед або якщо інший непропущений запуск Docs Agent був створений +протягом останньої години. Коли він запускається, він переглядає діапазон комітів +від вихідного SHA попереднього непропущеного Docs Agent до поточного `main`, +тож один щогодинний запуск може охопити всі зміни в main, накопичені з часу +останнього проходу документації. -Workflow `Test Performance Agent` — це event-driven смуга технічного обслуговування Codex -для повільних тестів. У нього немає окремого запуску за розкладом: -його може запустити успішний неботовий CI run push до `main`, але -він пропускається, якщо інший виклик через workflow-run уже виконався або виконується -цього дня за UTC. Ручний dispatch обходить це денне обмеження активності. -Смуга будує повний згрупований звіт продуктивності Vitest, дозволяє Codex -робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість -широких рефакторингів, потім повторно запускає повний звіт і відхиляє -зміни, які зменшують базову кількість тестів, що проходять. Якщо в базовому стані є тести зі збоями, -Codex може виправляти лише очевидні збої, а повний звіт після роботи агента -має пройти, перш ніж щось буде закомічено. Коли `main` просувається далі до того, -як bot push буде застосовано, смуга перебазовує перевірений патч, -повторно запускає `pnpm check:changed` і повторює push; -застарілі патчі з конфліктами пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб -дія Codex могла зберігати ту саму безпекову модель drop-sudo, що й docs agent. +Workflow `Test Performance Agent` — це maintenance lane Codex на основі подій +для повільних тестів. Він не має окремого запуску за розкладом: його може запустити +успішний CI run не-бота для push у `main`, але він пропускається, якщо інший запуск +через workflow-run уже виконався або виконується в ту саму добу UTC. Ручний запуск +обходить це добове обмеження активності. Lane будує згрупований звіт продуктивності +Vitest для повного набору тестів, дозволяє Codex вносити лише невеликі зміни +продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім +повторно запускає звіт для повного набору й відхиляє зміни, які зменшують базову +кількість успішних тестів. Якщо в базі є тести, що падають, Codex може виправляти +лише очевидні збої, і звіт повного набору після роботи агента має пройти повністю, +перш ніж щось буде закомічено. Коли `main` просувається вперед до того, як bot push +буде застосовано, lane перебазовує перевірений патч, повторно запускає +`pnpm check:changed` і повторює спробу push; конфліктні застарілі патчі пропускаються. +Він використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму +безпечну модель без `sudo`, що й docs agent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -67,70 +67,70 @@ gh workflow run duplicate-after-merge.yml \ | Завдання | Призначення | Коли запускається | | -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- | -| `preflight` | Визначає зміни лише в документації, змінені межі, змінені extensions і будує маніфест 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, перевірки 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` | Шарди основних Node-тестів, без channel, bundled, contract і extension-смуг | Зміни, релевантні для Node | -| `extension-fast` | Точкові тести лише для змінених bundled plugins | Pull request зі змінами в extension | -| `check` | Шардований еквівалент основної локальної перевірки: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Архітектурні, boundary, extension-surface guards, package-boundary і gateway-watch шарди | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke startup-memory | Зміни, релевантні для Node | -| `checks` | Перевіряльник для built-artifact channel tests плюс сумісність Node 22 лише для push | Зміни, релевантні для Node | +| `preflight` | Визначення змін лише в документації, змінених областей, змінених extensions і побудова маніфесту CI | Завжди для non-draft push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | +| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory npm | Завжди для non-draft push і PR | +| `security-fast` | Обов’язковий агрегатор для швидких завдань безпеки | Завжди для non-draft 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` | Шарди основних Node-тестів, за винятком channel, bundled, contract і extension lanes | Зміни, пов’язані з Node | +| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request із змінами в extension | +| `check` | Еквівалент основної локальної перевірки, розбитої на шарди: prod types, lint, guards, test types і strict smoke | Зміни, пов’язані з Node | +| `check-additional` | Шарди архітектурних, boundary, extension-surface, package-boundary і gateway-watch перевірок | Зміни, пов’язані з Node | +| `build-smoke` | Smoke-тести built-CLI і smoke-тест пам’яті під час запуску | Зміни, пов’язані з Node | +| `checks` | Верифікатор для built-artifact channel tests плюс сумісність Node 22 лише для push | Зміни, пов’язані з Node | | `check-docs` | Форматування документації, lint і перевірки зламаних посилань | Змінено документацію | -| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні для Python Skills | -| `checks-windows` | Специфічні для Windows тестові смуги | Зміни, релевантні для Windows | -| `macos-node` | Смуга тестів TypeScript на macOS із використанням спільних built artifacts | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Модульні тести Android для обох flavor плюс одна збірка debug APK | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх main CI або ручний dispatch | +| `skills-python` | Ruff + pytest для Skills на Python | Зміни, пов’язані з Python Skills | +| `checks-windows` | Windows-специфічні тестові смуги | Зміни, пов’язані з Windows | +| `macos-node` | Смуга тестів TypeScript на macOS з використанням спільних built artifacts | Зміни, пов’язані з macOS | +| `macos-swift` | Lint, збірка і тести Swift для застосунку macOS | Зміни, пов’язані з macOS | +| `android` | Android unit-тести для обох flavor плюс одна debug APK збірка | Зміни, пов’язані з Android | +| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успішний Main CI або ручний запуск | -## Порядок fail-fast +## Порядок Fail-Fast -Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускатимуться дорогі: +Завдання впорядковані так, щоб дешеві перевірки падали раніше, ніж запустяться дорогі: 1. `preflight` вирішує, які смуги взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих artifact- і platform-matrix-завдань. -3. `build-artifacts` виконується паралельно зі швидкими Linux-смугами, щоб downstream-споживачі могли стартувати, щойно спільна збірка готова. -4. Після цього розгалужуються важчі platform- і 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-смугами, щоб downstream-споживачі могли стартувати щойно буде готова спільна збірка. +4. Після цього розгалужуються важчі платформні смуги й смуги виконання: `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`. -Логіка меж знаходиться в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Зміни workflow CI перевіряють граф Node CI плюс lint workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці platform-смуги лишаються прив’язаними до змін у платформенному коді. -Перевірки Windows Node прив’язані до специфічних для Windows обгорток process/path, npm/pnpm/UI runner helpers, конфігурації package manager і поверхонь workflow CI, які запускають цю смугу; не пов’язані зміни вихідного коду, plugin, install-smoke і лише тестів залишаються на Linux Node-смугах, щоб не резервувати Windows worker на 16 vCPU заради покриття, яке вже проходить у звичайних test 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. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin з тайм-аутом команди 120 секунд. Повний шлях зберігає покриття QR package install і installer Docker/update для нічних запусків за розкладом, ручних dispatch, workflow-call release checks і pull request, які справді торкаються поверхонь installer/package/Docker. Push у `main`, включно з merge commits, не примушують запускати повний шлях; коли логіка changed-scope намагається запитати повне покриття для push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації. Повільний smoke Bun global install для image-provider окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow release checks, а ручні dispatch `install-smoke` можуть його ввімкнути, але pull request і push у `main` його не запускають. Тести QR та installer Docker зберігають власні install-орієнтовані Dockerfile. Локальний агрегат `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image `scripts/e2e/Dockerfile`, а потім запускає live/E2E smoke lanes із зваженим планувальником і `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM` і кількість слотів tail-pool 10, чутливих до provider, через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких смуг за замовчуванням становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`, щоб смуги npm install і multi-service не перевантажували Docker, поки легші смуги все ще заповнюють доступні слоти. Запуски смуг за замовчуванням розносяться на 2 секунди, щоб уникати локальних штормів створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегат за замовчуванням припиняє планування нових pooled lanes після першої помилки, а кожна смуга має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Повторно використовуваний workflow live/E2E віддзеркалює шаблон спільного image, збираючи й публікуючи один Docker E2E image з тегом SHA у GHCR перед Docker matrix, а потім запускає matrix з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований workflow live/E2E щодня запускає повний Docker-набір релізного шляху. Повна матриця bundled update/channel залишається ручною/повною, оскільки виконує повторні справжні проходи `npm update` і `doctor repair`. +Логіка визначення області змін знаходиться в `scripts/ci-changed-scope.mjs` і покривається unit-тестами в `src/scripts/ci-changed-scope.test.ts`. +Зміни у workflow CI перевіряють граф Node CI і lint workflow, але самі по собі не примушують запускати native-збірки Windows, Android або macOS; ці платформні смуги й далі залежать лише від змін у коді відповідних платформ. +Перевірки Windows Node обмежені Windows-специфічними wrappers для process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цю смугу; не пов’язані зміни у коді, plugins, install-smoke і лише тестах залишаються на Linux Node lanes, щоб не резервувати Windows worker із 16 vCPU для покриття, яке вже забезпечується звичайними test 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 jobs. Зміни лише у вихідному коді bundled plugin, лише в тестах і лише в документації не резервують Docker workers. Швидкий шлях один раз збирає root Dockerfile image, перевіряє CLI, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений профіль Docker для bundled-plugin із тайм-аутом команди 120 секунд. Повний шлях зберігає покриття встановлення QR package і installer Docker/update для нічних запусків за розкладом, ручних запусків, workflow-call release checks і pull request, які справді торкаються поверхонь installer/package/Docker. Push у `main`, включно з merge commits, не примушують повний шлях; коли логіка changed-scope вимагала б повне покриття для push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної перевірки. Повільний smoke для Bun global install image-provider додатково захищається прапорцем `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow release checks, а ручні запуски `install-smoke` можуть явно його ввімкнути, але pull request і push у `main` його не запускають. Тести QR і installer Docker мають власні Dockerfile, зосереджені на встановленні. Локальний агрегат `test:docker:all` попередньо збирає один спільний live-test image і один built-app image `scripts/e2e/Dockerfile`, а потім запускає live/E2E smoke lanes із ваговим планувальником і `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову кількість слотів основного пулу — 10 — через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до provider, — 10 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких смуг за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`, щоб смуги npm install і multi-service не перевантажували Docker, поки легші смуги все ще використовують доступні слоти. Запуски смуг за замовчуванням розносяться на 2 секунди, щоб уникати локальних штормів створення контейнерів Docker; перевизначте через `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 lanes використовують жорсткіші індивідуальні обмеження. Повторно використовуваний workflow live/E2E віддзеркалює шаблон спільного image: він збирає і публікує один GHCR Docker E2E image з тегом SHA перед Docker matrix, а потім запускає матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Workflow scheduled live/E2E щодня запускає повний Docker suite за релізним сценарієм. Матрицю bundled update поділено за ціллю оновлення, щоб повторні проходи npm update і doctor repair можна було шардувати разом з іншими bundled checks. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіше ставиться до архітектурних меж, ніж широка platform-scope CI: зміни в core production запускають typecheck для core prod плюс тести core, зміни лише в тестах core запускають лише typecheck/тести для core test, зміни в extension production запускають typecheck для extension prod плюс тести extension, а зміни лише в тестах extension запускають лише typecheck/тести для extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extension, оскільки extension залежать від цих контрактів core. Підвищення версії лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config переходять у безпечний режим і запускають усі смуги. +Локальна логіка changed-lane знаходиться в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіше ставиться до архітектурних меж, ніж широка платформна область CI: зміни core production запускають typecheck для core prod плюс тести core, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни extension production запускають typecheck для extension prod плюс тести extension, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extensions, оскільки extensions залежать від цих core-контрактів. Підвищення версії лише в метаданих релізу запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно переводять перевірку на всі смуги. -Для push матриця `checks` додає смугу `compat-node22`, що виконується лише для push. Для pull request ця смуга пропускається, і матриця зосереджується на звичайних test/channel-смугах. +Для push матриця `checks` додає lane `compat-node22`, який запускається лише для push. Для pull request цей lane пропускається, і матриця залишається зосередженою на звичайних test/channel lanes. -Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим і не резервувало зайві runner-и: channel contracts виконуються як три зважені шарди, тести bundled plugin балансуються між шістьма workers для extension, невеликі core unit-смуги об’єднані попарно, auto-reply працює на трьох збалансованих workers замість шести маленьких, а конфігурації agentic gateway/plugin розподілені між наявними source-only agentic Node-завданнями замість очікування built artifacts. Широкі browser-, QA-, media- та різні plugin-тести використовують свої виділені конфігурації Vitest замість спільного catch-all для plugin. Завдання шардованих extension запускають до двох груп конфігурацій plugin одночасно з одним worker Vitest на групу та збільшеною купою Node, щоб партії plugin з великою кількістю імпортів не створювали додаткові CI-завдання. Широка смуга agents використовує спільний file-parallel scheduler Vitest, оскільки в ній домінують імпорти/планування, а не один окремий повільний тестовий файл. `runtime-config` виконується разом із шардом infra core-runtime, щоб спільний runtime-shard не тягнув хвіст. `check-additional` тримає разом package-boundary compile/canary-роботи й відокремлює архітектуру runtime topology від покриття gateway watch; шард boundary guard запускає свої невеликі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і шард core support-boundary виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі імена перевірок як легкі verifier-завдання та уникаючи двох додаткових workers Blacksmith і другої черги споживачів artifact. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає debug APK для Play. Для third-party flavor немає окремого source set або manifest; його смуга unit-тестів усе одно компілює цей flavor з прапорцями BuildConfig для SMS/call-log, водночас уникаючи дубльованого завдання пакування debug APK при кожному push, релевантному для Android. -`extension-fast` призначено лише для PR, оскільки push-запуски вже виконують повні шарди bundled plugin. Це дає зворотний зв’язок для changed-plugin під час рев’ю, не резервуючи додатковий worker Blacksmith на `main` для покриття, яке вже є в `checks-node-extensions`. +Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: channel contracts запускаються як три зважені шарди, тести bundled plugin балансуються між шістьма extension worker-ами, невеликі core unit lanes поєднуються попарно, auto-reply працює на трьох збалансованих worker-ах замість шести дрібних worker-ів, а agentic gateway/plugin configs розподіляються між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі тести browser, QA, media і miscellaneous plugin використовують свої окремі конфігурації Vitest замість спільного універсального набору plugin. Завдання extension shard запускають до двох груп конфігурацій plugin одночасно з одним worker-ом Vitest на групу та більшим heap Node, щоб import-інтенсивні пакети plugin не створювали зайві завдання CI. Широка agents lane використовує спільний планувальник файлового паралелізму Vitest, оскільки тут домінують import/планування, а не один окремий повільний test file. `runtime-config` запускається разом із shard `infra core-runtime`, щоб спільний shard runtime не володів хвостом. `check-additional` тримає разом package-boundary compile/canary роботу і відокремлює архітектуру runtime topology від покриття gateway watch; shard boundary guard запускає свої малі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і shard core support-boundary запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі імена перевірок як легкі завдання-верифікатори, водночас уникаючи двох додаткових Blacksmith worker-ів і другої черги споживачів артефактів. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Flavor third-party не має окремого source set або manifest; його lane unit-тестів усе одно компілює цей flavor з прапорцями BuildConfig для SMS/call-log, водночас уникаючи дубльованого завдання пакування debug APK для кожного Android-релевантного push. +`extension-fast` є лише для PR, оскільки push-запуски вже виконують повні шарди bundled plugin. Це дає швидкий зворотний зв’язок щодо змінених plugin для рев’ю, не резервуючи додатковий Blacksmith worker у `main` для покриття, яке вже присутнє в `checks-node-extensions`. -GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо тільки найновіший run для того самого ref також не завершується збоєм. Агреговані шардовані перевірки використовують `!cancelled() && always()`, тому вони все ще повідомляють про звичайні збої шардів, але не стають у чергу після того, як увесь workflow уже був витіснений. -Ключ concurrency CI має версію (`CI-v7-*`), тож zombie на боці GitHub у старій queue group не може безкінечно блокувати новіші запуски main. +GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Вважайте це шумом CI, якщо тільки найновіший запуск для того самого ref також не завершується помилкою. Агреговані shard-перевірки використовують `!cancelled() && always()`, щоб вони все одно повідомляли про звичайні збої shard-ів, але не ставали в чергу після того, як весь workflow уже був витіснений. +Ключ concurrency у CI має версію (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безкінечно блокувати новіші запуски main. ## Runner-и -| Runner | Завдання | -| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки channel contract, шарди `check` окрім lint, шарди й агрегати `check-additional`, aggregate verifiers тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів 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`; форки переходять на `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки переходять на `macos-latest` | +| Runner | Завдання | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, перевірки channel contract, розбиті на шарди, шарди `check`, окрім lint, шарди й агрегати `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, шарди Linux Node-тестів, шарди тестів 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 # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane -pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guards +pnpm check # швидка локальна перевірка: production tsgo + lint, розбитий на шарди + паралельні швидкі guards pnpm check:test-types pnpm check:timed # та сама перевірка з таймінгами для кожного етапу pnpm build:strict-smoke @@ -140,9 +140,9 @@ pnpm test # тести vitest pnpm test:channels pnpm test:contracts:channels pnpm check:docs # форматування документації + lint + зламані посилання -pnpm build # збірка dist, коли важливі смуги CI artifact/build-smoke -node scripts/ci-run-timings.mjs # підсумувати wall time, queue time і найповільніші завдання -node scripts/ci-run-timings.mjs --recent 10 # порівняти останні успішні запуски CI для main +pnpm build # зібрати dist, коли важливі смуги CI artifact/build-smoke +node scripts/ci-run-timings.mjs # підсумувати загальний час, час у черзі та найповільніші завдання +node scripts/ci-run-timings.mjs --recent 10 # порівняти нещодавні успішні запуски main CI 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 ``` @@ -150,4 +150,4 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Пов’язане - [Огляд встановлення](/uk/install) -- [Канали релізів](/uk/install/development-channels) +- [Канали релізу](/uk/install/development-channels) diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 88690a3a6..11df82be8 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,25 +1,25 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресійних тестів для помилок моделі/провайдера + - Додавання регресійних тестів для багів моделі/провайдера - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: набори unit/e2e/live, Docker-ранери та що охоплює кожен тест' +summary: 'Набір для тестування: unit/e2e/live набори, Docker runners і що саме охоплює кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-24T19:51:30Z" + generated_at: "2026-04-24T22:51:38Z" model: gpt-5.4 provider: openai - source_hash: 437a49f67b775f63670f00efec63e268e02e74e072d92a645d427b975028e8be + source_hash: d8d70027f15c4e12198d6e8fa8cb74086c30dd405d6681d78ecb811bd448e838 source_path: help/testing.md workflow: 15 --- -OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір Docker-ранерів. Цей документ — інструкція «як ми тестуємо»: +OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір Docker runners. Цей документ — посібник «як ми тестуємо»: - Що охоплює кожен набір (і що він навмисно _не_ охоплює). - Які команди запускати для типових сценаріїв роботи (локально, перед push, налагодження). -- Як live-тести знаходять облікові дані й вибирають моделі/провайдерів. -- Як додавати регресії для реальних проблем моделей/провайдерів. +- Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. +- Як додавати регресійні тести для реальних проблем із моделями/провайдерами. ## Швидкий старт @@ -27,166 +27,163 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` - Швидший локальний запуск усього набору на потужній машині: `pnpm test:max` -- Прямий цикл watch для Vitest: `pnpm test:watch` -- Пряме націлення на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Якщо ви ітеруєте лише над однією помилкою, спочатку віддавайте перевагу цільовим запускам. +- Прямий цикл спостереження Vitest: `pnpm test:watch` +- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Коли ви ітеруєтеся над однією помилкою, спочатку віддавайте перевагу цільовим запускам. - QA-сайт на базі Docker: `pnpm qa:lab:up` -- QA-lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- QA lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Коли ви змінюєте тести або хочете більше впевненості: +Коли ви змінюєте тести або хочете більшої впевненості: - Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` -Під час налагодження реальних провайдерів/моделей (потрібні справжні облікові дані): +Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): - Live-набір (моделі + перевірки інструментів/зображень Gateway): `pnpm test:live` -- Тихий запуск одного live-файла: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Docker-обхід live-моделей: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід плюс невелику перевірку в стилі читання файла. - Моделі, у метаданих яких заявлено вхід `image`, також виконують невеликий хід із зображенням. +- Цільовий запуск одного live-файлу в тихому режимі: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Docker live model sweep: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий хід плюс невелику перевірку у стилі читання файлу. + Моделі, чиї метадані оголошують вхід `image`, також виконують невеликий хід із зображенням. Вимкніть додаткові перевірки через `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або - `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдерів. - - Покриття в CI: щоденний `OpenClaw Scheduled Live And E2E Checks` і ручний + `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. + - Покриття в CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні `OpenClaw Release Checks` обидва викликають повторно використовуваний workflow live/E2E з - `include_live_suites: true`, який включає окремі матричні завдання Docker live model, - розшардовані за провайдером. - - Для точкових повторних запусків у CI виконайте `OpenClaw Live And E2E Checks (Reusable)` + `include_live_suites: true`, що включає окремі матричні jobs Docker live model, + розбиті за провайдером. + - Для точкових повторних запусків у CI запустіть `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові високосигнальні секрети провайдерів до `scripts/ci-hydrate-live-auth.sh` - а також до `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його - запланованих/release-викликів. -- Native Codex smoke для bind-chat: `pnpm test:docker:live-codex-bind` - - Запускає Docker live-lane проти шляху app-server Codex, прив’язує синтетичний + - Додавайте нові високосигнальні секрети провайдерів до `scripts/ci-hydrate-live-auth.sh`, а також до `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його + викликів для scheduled/release. +- Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` + - Запускає Docker live lane проти шляху app-server Codex, прив’язує синтетичний Slack DM через `/codex bind`, виконує `/codex fast` і - `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення-зображення - маршрутизуються через native binding Plugin, а не через ACP. -- Smoke-перевірка вартості Moonshot/Kimi: якщо встановлено `MOONSHOT_API_KEY`, виконайте - `openclaw models list --provider moonshot --json`, а потім запустіть ізольований + `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення із зображенням + маршрутизуються через нативну прив’язку plugin, а не через ACP. +- Moonshot/Kimi cost smoke: якщо встановлено `MOONSHOT_API_KEY`, виконайте + `openclaw models list --provider moonshot --json`, а потім виконайте ізольований `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` проти `moonshot/kimi-k2.6`. Переконайтеся, що JSON повідомляє Moonshot/K2.6 і що - транскрипт асистента зберігає нормалізоване `usage.cost`. + транскрипт асистента зберігає нормалізований `usage.cost`. -Порада: якщо вам потрібен лише один збійний випадок, звужуйте live-тести через allowlist env vars, описані нижче. +Порада: коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через змінні середовища allowlist, описані нижче. -## QA-специфічні ранери +## Runner-и, специфічні для QA -Ці команди стоять поруч із основними наборами тестів, коли вам потрібен реалізм QA-lab: +Ці команди розташовані поруч з основними наборами тестів, коли вам потрібен реалізм QA-lab: -CI запускає QA Lab в окремих workflow. `Parity gate` запускається для відповідних PR і -через manual dispatch з mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на -`main` і через manual dispatch із mock parity gate, live Matrix lane і -live Telegram lane під керуванням Convex як паралельні jobs. `OpenClaw Release Checks` -запускає ті самі lanes перед затвердженням релізу. +CI запускає QA Lab в окремих workflow. `Parity gate` запускається на відповідних PR і +з ручного dispatch із mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на +`main` і з ручного dispatch із mock parity gate, live Matrix lane та live Telegram lane під керуванням Convex як паралельними jobs. `OpenClaw Release Checks` +запускає ті самі lane-и перед погодженням релізу. - `pnpm openclaw qa suite` - Запускає сценарії QA на базі репозиторію безпосередньо на хості. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими - worker-процесами gateway. `qa-channel` типово використовує concurrency 4 (обмежене - кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість - worker-ів, або `--concurrency 1` для старішого послідовного lane. - - Завершується з ненульовим кодом, якщо хоч один сценарій зазнав збою. Використовуйте `--allow-failures`, якщо + worker-ами Gateway. `qa-channel` за замовчуванням має concurrency 4 (обмежену + кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати + кількість worker-ів, або `--concurrency 1` для старого послідовного lane. + - Завершується з ненульовим кодом, якщо будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - - Підтримує режими провайдерів `live-frontier`, `mock-openai` і `aimock`. + - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. `aimock` запускає локальний сервер провайдера на базі AIMock для експериментального - покриття фікстур і protocol-mock без заміни lane `mock-openai`, який знає про сценарії. + покриття fixture і протокольних mock-ів без заміни сценарно-орієнтованого + lane `mock-openai`. - `pnpm openclaw qa suite --runner multipass` - Запускає той самий QA-набір усередині тимчасової Linux VM Multipass. - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості. - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. - - Live-запуски передають підтримувані QA-входи автентифікації, які практично використовувати в гостьовій системі: - ключі провайдерів на основі env, шлях до конфігурації QA live provider і `CODEX_HOME`, якщо він є. + - Live-запуски передають підтримувані QA-входи автентифікації, практичні для гостьової системи: + ключі провайдера на базі env, шлях до конфігурації QA live provider і `CODEX_HOME`, якщо він присутній. - Каталоги виводу мають залишатися в межах кореня репозиторію, щоб гостьова система могла записувати назад через - змонтований робочий простір. - - Записує звичайний QA-звіт + підсумок, а також логи Multipass у + змонтований workspace. + - Записує звичайний QA report + summary, а також журнали Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Запускає QA-сайт на базі Docker для операторського QA. + - Запускає QA-сайт на базі Docker для QA-роботи в операторському стилі. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm tarball із поточного checkout, глобально встановлює його в - Docker, виконує неінтерактивний onboarding з OpenAI API key, за замовчуванням налаштовує Telegram, - перевіряє, що ввімкнення Plugin встановлює runtime-залежності на вимогу, - запускає doctor і виконує один локальний хід агента проти замоканого OpenAI endpoint. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий lane - встановлення з пакета з Discord. + - Створює npm tarball із поточного checkout, глобально встановлює його в + Docker, виконує неінтерактивний onboarding з API-ключем OpenAI, за замовчуванням налаштовує Telegram, + перевіряє, що ввімкнення plugin встановлює runtime dependencies на вимогу, + запускає doctor і виконує один локальний хід агента проти змоканого endpoint OpenAI. + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий + lane пакетного встановлення з Discord. - `pnpm test:docker:npm-telegram-live` - - Встановлює опублікований пакет OpenClaw у Docker, виконує onboarding + - Встановлює опублікований пакет OpenClaw у Docker, виконує onboarding для встановленого пакета, налаштовує Telegram через встановлений CLI, а потім повторно використовує - live Telegram QA lane із цим встановленим пакетом як SUT Gateway. - - Типово використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`. + QA lane live Telegram із цим встановленим пакетом як SUT Gateway. + - За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`. - Використовує ті самі env-облікові дані Telegram або джерело облікових даних Convex, що й - `pnpm openclaw qa telegram`. Для CI/автоматизації релізів установіть - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` разом із - `OPENCLAW_QA_CONVEX_SITE_URL` і секретом ролі. Якщо + `pnpm openclaw qa telegram`. Для автоматизації CI/release встановіть + `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` плюс + `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі. Якщо `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex присутні в CI, - Docker-обгортка автоматично вибирає Convex. - - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільну + Docker wrapper автоматично вибирає Convex. + - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільний `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цього lane. - - GitHub Actions надає цей lane як ручний workflow для мейнтейнерів + - GitHub Actions надає цей lane як ручний workflow для супровідника `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує - середовище `qa-live-shared` і lease-и облікових даних Convex для CI. + середовище `qa-live-shared` і оренду CI-облікових даних Convex. - `pnpm test:docker:bundled-channel-deps` - - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає вбудовані channel/plugins через редагування конфігурації. - - Перевіряє, що виявлення під час setup залишає runtime-залежності - неналаштованих Plugin відсутніми, що перший налаштований запуск Gateway або doctor встановлює runtime-залежності кожного вбудованого - Plugin на вимогу, і що другий перезапуск не перевстановлює залежності, які вже були активовані. - - Також встановлює відому старішу npm baseline-версію, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що doctor кандидата - після оновлення відновлює runtime-залежності вбудованих channel без виправлення postinstall - з боку harness. + - Пакує й установлює поточну збірку OpenClaw у Docker, запускає Gateway з налаштованим OpenAI, а потім вмикає bundled channel/plugin через редагування конфігурації. + - Перевіряє, що виявлення налаштування залишає runtime dependencies + неналаштованих plugin відсутніми, що перший налаштований запуск Gateway або doctor + встановлює runtime dependencies кожного bundled plugin на вимогу, і що другий перезапуск не перевстановлює залежності, які вже були активовані. + - Також установлює відому старішу npm baseline, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що + `doctor` кандидата після оновлення відновлює bundled channel runtime dependencies без виправлення `postinstall` з боку harness. - `pnpm openclaw qa aimock` - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування протоколу. - `pnpm openclaw qa matrix` - Запускає live QA lane Matrix проти тимчасового homeserver Tuwunel на базі Docker. - - Цей QA-хост наразі призначений лише для репозиторію/розробки. Упаковані встановлення OpenClaw не постачають - `qa-lab`, тому не надають `openclaw qa`. - - Checkout-и репозиторію завантажують вбудований runner безпосередньо; окремий крок встановлення Plugin не потрібен. - - Підготовлює трьох тимчасових користувачів Matrix (`driver`, `sut`, `observer`) плюс одну приватну кімнату, а потім запускає дочірній QA gateway із реальним Plugin Matrix як транспортом SUT. - - Типово використовує зафіксований стабільний образ Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Перевизначайте через `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, коли потрібно протестувати інший образ. - - Matrix не надає спільних прапорців джерела облікових даних, оскільки цей lane локально створює тимчасових користувачів. - - Записує QA-звіт Matrix, підсумок, артефакт observed-events і комбінований лог stdout/stderr у `.artifacts/qa-e2e/...`. - - Типово виводить прогрес і примусово застосовує жорсткий timeout виконання через `OPENCLAW_QA_MATRIX_TIMEOUT_MS` (типово 30 хвилин). Очищення обмежується `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS`, а у випадку збою включається команда відновлення `docker compose ... down --remove-orphans`. + - Цей QA-хост наразі призначений лише для repo/dev. Пакетні встановлення OpenClaw не постачають + `qa-lab`, тому вони не надають `openclaw qa`. + - Checkout-и репозиторію завантажують bundled runner безпосередньо; окремий крок встановлення plugin не потрібен. + - Надає три тимчасові користувачі Matrix (`driver`, `sut`, `observer`) плюс одну приватну кімнату, а потім запускає дочірній процес QA gateway із реальним plugin Matrix як транспортом SUT. + - За замовчуванням використовує зафіксований стабільний образ Tuwunel `ghcr.io/matrix-construct/tuwunel:v1.5.1`. Перевизначайте через `OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE`, якщо потрібно протестувати інший образ. + - Matrix не надає спільні прапорці джерела облікових даних, тому що lane локально створює тимчасових користувачів. + - Записує Matrix QA report, summary, артефакт observed-events і комбінований журнал виводу stdout/stderr до `.artifacts/qa-e2e/...`. + - За замовчуванням виводить прогрес і примусово застосовує жорсткий timeout виконання через `OPENCLAW_QA_MATRIX_TIMEOUT_MS` (типово 30 хвилин). Cleanup обмежується `OPENCLAW_QA_MATRIX_CLEANUP_TIMEOUT_MS`, а помилки включають команду відновлення `docker compose ... down --remove-orphans`. - `pnpm openclaw qa telegram` - - Запускає live QA lane Telegram проти реальної приватної групи, використовуючи токени driver і SUT bot з env. + - Запускає live QA lane Telegram проти реальної приватної групи, використовуючи токени ботів driver і SUT з env. - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим Telegram chat id. - - Підтримує `--credential-source convex` для спільних пулінгових облікових даних. Типово використовуйте режим env або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб перейти на спільні lease-и. - - Завершується з ненульовим кодом, якщо хоч один сценарій зазнав збою. Використовуйте `--allow-failures`, якщо + - Підтримує `--credential-source convex` для спільних пулів облікових даних. За замовчуванням використовуйте режим env, або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб перейти на pooled leases. + - Завершується з ненульовим кодом, якщо будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - - Потребує двох різних bot в одній приватній групі, причому SUT bot має мати Telegram username. - - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати трафік bot у групі. - - Записує QA-звіт Telegram, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту на надсилання driver до спостережуваної відповіді SUT. + - Потребує двох різних ботів в одній приватній групі, причому бот SUT має мати Telegram username. + - Для стабільного спостереження взаємодії між ботами увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох ботів і переконайтеся, що бот driver може спостерігати трафік ботів у групі. + - Записує Telegram QA report, summary і артефакт observed-messages до `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту на надсилання driver до спостережуваної відповіді SUT. -Live transport lanes мають один спільний стандартний контракт, щоб нові транспорти не розходилися в поведінці: +Live transport lane-и мають спільний стандартний контракт, щоб нові транспорти не дрейфували: `qa-channel` залишається широким синтетичним QA-набором і не входить до матриці покриття live transport. -| Lane | Канарка | Керування згадками | Блок allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Follow-up у треді | Ізоляція тредів | Спостереження за реакціями | Команда help | -| -------- | ------- | ------------------ | -------------- | ------------------------- | ----------------------------- | ----------------- | --------------- | -------------------------- | ------------ | -| Matrix | x | x | x | x | x | x | x | x | | -| Telegram | x | | | | | | | | x | +| Lane | Canary | Mention gating | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | +| -------- | ------ | -------------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | +| Matrix | x | x | x | x | x | x | x | x | | +| Telegram | x | | | | | | | | x | ### Спільні облікові дані Telegram через Convex (v1) Коли для `openclaw qa telegram` увімкнено `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`), -QA lab отримує ексклюзивний lease із пулу на базі Convex, підтримує Heartbeat -цього lease, поки lane виконується, і звільняє lease під час завершення роботи. +QA lab отримує ексклюзивну оренду з пулу на базі Convex, надсилає Heartbeat +для цієї оренди, поки lane виконується, і звільняє оренду під час завершення роботи. Еталонний каркас проєкту Convex: - `qa/convex-credential-broker/` -Обов’язкові env vars: +Обов’язкові змінні середовища: -- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад, `https://your-deployment.convex.site`) +- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад `https://your-deployment.convex.site`) - Один секрет для вибраної ролі: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` для `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` для `ci` - Вибір ролі облікових даних: - CLI: `--credential-role maintainer|ci` - - Значення env за замовчуванням: `OPENCLAW_QA_CREDENTIAL_ROLE` (типово `ci` у CI, інакше `maintainer`) + - Типове значення env: `OPENCLAW_QA_CREDENTIAL_ROLE` (типово `ci` у CI, інакше `maintainer`) -Необов’язкові env vars: +Необов’язкові змінні середовища: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (типово `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (типово `30000`) @@ -198,10 +195,10 @@ QA lab отримує ексклюзивний lease із пулу на базі `OPENCLAW_QA_CONVEX_SITE_URL` у звичайному режимі роботи має використовувати `https://`. -Адміністративні команди мейнтейнера (pool add/remove/list) потребують +Команди адміністрування для супровідників (додавання/видалення/перелік пулу) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -CLI-хелпери для мейнтейнерів: +CLI-хелпери для супровідників: ```bash pnpm openclaw qa credentials doctor @@ -211,29 +208,30 @@ pnpm openclaw qa credentials remove --credential-id ``` Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, секрети broker, -префікс endpoint, HTTP timeout і доступність admin/list без виведення -значень секретів. Використовуйте `--json` для машиночитаного виводу в скриптах і утилітах CI. +префікс endpoint, timeout HTTP і доступність admin/list без виведення +значень секретів. Використовуйте `--json` для машиночитного виводу в скриптах і +утилітах CI. Контракт endpoint за замовчуванням (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - Успіх: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Вичерпано/можна повторити спробу: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Вичерпано/можна повторити: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Запит: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - Успіх: `{ status: "ok" }` (або порожній `2xx`) - `POST /release` - Запит: `{ kind, ownerId, actorRole, credentialId, leaseToken }` - Успіх: `{ status: "ok" }` (або порожній `2xx`) -- `POST /admin/add` (лише секрет maintainer) +- `POST /admin/add` (лише секрет супровідника) - Запит: `{ kind, actorId, payload, note?, status? }` - Успіх: `{ status: "ok", credential }` -- `POST /admin/remove` (лише секрет maintainer) +- `POST /admin/remove` (лише секрет супровідника) - Запит: `{ credentialId, actorId }` - Успіх: `{ status: "ok", changed, credential }` - - Захист активного lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (лише секрет maintainer) + - Захист активної оренди: `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (лише секрет супровідника) - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` @@ -243,57 +241,57 @@ pnpm openclaw qa credentials remove --credential-id - `groupId` має бути рядком із числовим Telegram chat id. - `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload. -### Додавання channel до QA +### Додавання каналу до QA -Додавання channel до markdown-системи QA потребує рівно двох речей: +Додавання каналу до markdown-системи QA потребує рівно двох речей: -1. Транспортного адаптера для channel. -2. Пакета сценаріїв, який перевіряє контракт channel. +1. Транспортного адаптера для каналу. +2. Набору сценаріїв, який перевіряє контракт каналу. -Не додавайте новий кореневий QA-командний простір верхнього рівня, якщо спільний хост `qa-lab` -може керувати цим процесом. +Не додавайте новий кореневий QA-командний простір верхнього рівня, якщо спільний хост `qa-lab` може +керувати цим потоком. -`qa-lab` володіє спільною механікою хоста: +`qa-lab` володіє спільною хост-механікою: - коренем команди `openclaw qa` - запуском і завершенням набору -- паралелізмом worker-ів +- concurrency worker-ів - записом артефактів - генерацією звітів - виконанням сценаріїв -- alias сумісності для старіших сценаріїв `qa-channel` +- псевдонімами сумісності для старіших сценаріїв `qa-channel` -Runner Plugins володіють транспортним контрактом: +Runner plugins володіють транспортним контрактом: - як `openclaw qa ` монтується під спільним коренем `qa` - як Gateway налаштовується для цього транспорту - як перевіряється готовність - як інжектуються вхідні події - як спостерігаються вихідні повідомлення -- як відкриваються транскрипти й нормалізований стан транспорту +- як надаються транскрипти й нормалізований стан транспорту - як виконуються дії на основі транспорту -- як обробляється специфічне для транспорту скидання або очищення +- як обробляється специфічний для транспорту reset або cleanup -Мінімальний поріг прийняття для нового channel: +Мінімальний поріг впровадження для нового каналу такий: -1. Залишайте `qa-lab` власником спільного кореня `qa`. -2. Реалізуйте transport runner на спільному шві хоста `qa-lab`. -3. Залишайте специфічну для транспорту механіку всередині runner Plugin або harness channel. +1. Зберігайте `qa-lab` як власника спільного кореня `qa`. +2. Реалізуйте transport runner на спільному seam хоста `qa-lab`. +3. Тримайте специфічну для транспорту механіку всередині runner plugin або harness каналу. 4. Монтуйте runner як `openclaw qa ` замість реєстрації конкуруючої кореневої команди. - Runner Plugins мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. - Залишайте `runtime-api.ts` легким; ліниві CLI і виконання runner мають залишатися за окремими entrypoint. -5. Пишіть або адаптуйте markdown-сценарії в тематичних каталогах `qa/scenarios/`. -6. Для нових сценаріїв використовуйте універсальні хелпери сценаріїв. -7. Залишайте наявні alias сумісності працездатними, якщо тільки репозиторій не виконує навмисну міграцію. + Runner plugins мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. + Тримайте `runtime-api.ts` легким; відкладене виконання CLI і runner має залишатися за окремими entrypoint. +5. Створюйте або адаптуйте markdown-сценарії в тематичних каталогах `qa/scenarios/`. +6. Використовуйте generic-хелпери сценаріїв для нових сценаріїв. +7. Зберігайте наявні псевдоніми сумісності робочими, якщо в репозиторії не виконується навмисна міграція. Правило прийняття рішення суворе: -- Якщо поведінку можна виразити один раз у `qa-lab`, розміщуйте її в `qa-lab`. -- Якщо поведінка залежить від одного транспорту channel, залишайте її в тому runner Plugin або harness Plugin. -- Якщо сценарію потрібна нова можливість, яку можуть використовувати більше ніж один channel, додавайте універсальний helper замість специфічної для channel гілки в `suite.ts`. +- Якщо поведінку можна один раз виразити в `qa-lab`, розміщуйте її в `qa-lab`. +- Якщо поведінка залежить від одного канального транспорту, тримайте її в runner plugin або harness цього plugin. +- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один канал, додайте generic-хелпер замість специфічної для каналу гілки в `suite.ts`. - Якщо поведінка має сенс лише для одного транспорту, залишайте сценарій специфічним для цього транспорту й явно зазначайте це в контракті сценарію. -Рекомендовані назви універсальних helper для нових сценаріїв: +Бажані назви generic-хелперів для нових сценаріїв: - `waitForTransportReady` - `waitForChannelReady` @@ -308,7 +306,7 @@ Runner Plugins володіють транспортним контрактом: - `formatTransportTranscript` - `resetTransport` -Alias сумісності залишаються доступними для наявних сценаріїв, зокрема: +Для наявних сценаріїв залишаються доступними псевдоніми сумісності, зокрема: - `waitForQaChannelReady` - `waitForOutboundMessage` @@ -316,113 +314,115 @@ Alias сумісності залишаються доступними для н - `formatConversationTranscript` - `resetBus` -Нова робота над channel має використовувати універсальні назви helper. -Alias сумісності існують, щоб уникнути міграції в один день, а не як модель для -написання нових сценаріїв. +Нова робота над каналами має використовувати generic-назви хелперів. +Псевдоніми сумісності існують, щоб уникнути одномоментної міграції, а не як модель для +створення нових сценаріїв. -## Набори тестів (що де запускається) +## Набори тестів (що і де запускається) -Сприймайте набори як «зростання реалізму» (і зростання нестабільності/вартості): +Думайте про набори як про «зростання реалізму» (і зростання flaky-поведінки/вартості): ### Unit / integration (типово) - Команда: `pnpm test` -- Конфігурація: ненацілені запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати багатопроєктні shard у конфігурації для кожного проєкту для паралельного планування -- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і дозволені node-тести `ui`, які охоплює `vitest.unit.config.ts` +- Конфігурація: ненацілені запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у конфігурації для кожного проєкту для паралельного планування +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і whitelist-нуті node-тести `ui`, які охоплює `vitest.unit.config.ts` - Обсяг: - Чисті unit-тести - - Внутрішньопроцесні integration-тести (автентифікація gateway, маршрутизація, інструментарій, парсинг, конфігурація) - - Детерміновані регресії для відомих помилок + - Інтеграційні тести в межах процесу (автентифікація Gateway, маршрутизація, інструменти, парсинг, конфігурація) + - Детерміновані регресії для відомих багів - Очікування: - Запускаються в CI - Реальні ключі не потрібні - Мають бути швидкими й стабільними - + - - Ненацілений `pnpm test` запускає дванадцять менших shard-конфігурацій (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського процесу root project. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори. - - `pnpm test --watch` усе ще використовує нативний граф проєктів root `vitest.config.ts`, оскільки цикл watch із багатьма shard непрактичний. - - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спочатку маршрутизують явні цілі файлів/каталогів через scope-lanes, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає витрат на повний запуск root project. - - `pnpm test:changed` розгортає змінені git-шляхи в ті самі scope-lanes, коли diff зачіпає лише routable source/test-файли; редагування config/setup усе ще повертаються до широкого повторного запуску root project. - - `pnpm check:changed` — звичайний розумний локальний gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata і tooling, а потім запускає відповідні typecheck/lint/test lanes. Зміни публічного Plugin SDK і plugin-contract включають один прохід валідації extension, оскільки extensions залежать від цих контрактів core. Зміни version bump лише в release metadata запускають цільові перевірки version/config/root-dependency замість повного набору, із захистом, який відхиляє зміни пакетів поза полем version верхнього рівня. - - Легкі unit-тести за імпортами з agents, commands, plugins, хелперів auto-reply, `plugin-sdk` та подібних чистих утилітних зон маршрутизуються через lane `unit-fast`, яка пропускає `test/setup-openclaw-runtime.ts`; файли зі станом/важким runtime залишаються на наявних lanes. - - Вибрані вихідні helper-файли `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих легких lanes, щоб редагування helper не змушували повторно запускати повний важкий набір для цього каталогу. - - `auto-reply` має три окремі бакети: top-level helper core, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій harness-роботі reply потрапляти в дешеві тести status/chunk/token. + - Ненацілені запуски `pnpm test` використовують дванадцять менших конфігурацій shard (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського процесу native root-project. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension витісняти не пов’язані набори. + - `pnpm test --watch` усе ще використовує native root граф проєкту `vitest.config.ts`, тому що цикл watch із кількома shards непрактичний. + - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спочатку маршрутизують явні цілі файлів/каталогів через scoped lanes, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску root project. + - `pnpm test:changed` розгортає змінені шляхи git у ті самі scoped lanes, коли diff зачіпає лише routable source/test файли; редагування config/setup усе ще повертаються до широкого повторного запуску root-project. + - `pnpm check:changed` — це звичайний розумний локальний gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata і tooling, а потім запускає відповідні typecheck/lint/test lanes. Зміни в публічному Plugin SDK і plugin-contract включають один прохід перевірки extension, тому що extensions залежать від цих контрактів core. Оновлення версій лише в release metadata запускають цільові перевірки version/config/root-dependency замість повного набору, із захистом, який відхиляє зміни пакета поза полем версії верхнього рівня. + - Unit-тести з легкими імпортами з agents, commands, plugins, хелперів auto-reply, `plugin-sdk` та подібних чистих утилітних зон маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані вихідні файли хелперів `plugin-sdk` і `commands` також зіставляють запуски в режимі changed з явними сусідніми тестами в цих легких lanes, тож зміни хелперів не змушують повторно запускати повний важкий набір для цього каталогу. + - `auto-reply` має три виділені блоки: top-level core хелпери, top-level інтеграційні тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness reply потрапляти в дешеві тести status/chunk/token. - + - - Коли ви змінюєте вхідні дані виявлення message-tool або runtime-контекст Compaction, + - Коли ви змінюєте входи виявлення message-tool або runtime-контекст compaction, зберігайте обидва рівні покриття. - - Додавайте сфокусовані helper-регресії для чистих меж маршрутизації й нормалізації. - - Підтримуйте здоровий стан integration-наборів вбудованого runner: + - Додавайте сфокусовані регресії хелперів для чистих меж + маршрутизації та нормалізації. + - Підтримуйте інтеграційні набори embedded runner у здоровому стані: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` і `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ці набори перевіряють, що scope id і поведінка Compaction усе ще проходять - через реальні шляхи `run.ts` / `compact.ts`; лише helper-тести - не є достатньою заміною для цих integration-шляхів. + - Ці набори перевіряють, що scoped id і поведінка compaction усе ще проходять + через реальні шляхи `run.ts` / `compact.ts`; тести лише на рівні хелперів + не є достатньою заміною для цих інтеграційних шляхів. - + - Базова конфігурація Vitest типово використовує `threads`. - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у root projects, e2e і live config. - - Lane root UI зберігає своє налаштування `jsdom` й optimizer, але також працює на - спільному неізольованому runner. - - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` - зі спільної конфігурації Vitest. + non-isolated runner у root projects, а також у конфігураціях e2e і live. + - Root UI lane зберігає свій `jsdom` setup і optimizer, але теж працює на + спільному non-isolated runner. + - Кожен shard `pnpm test` успадковує ті самі типові значення + `threads` + `isolate: false` зі спільної конфігурації Vitest. - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. + Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною + поведінкою V8. - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. - - Pre-commit hook відповідає лише за форматування. Він повторно додає до stage відформатовані файли - і не запускає lint, typecheck або тести. - - Явно запускайте `pnpm check:changed` перед передачею чи push, коли - вам потрібен розумний локальний gate. Зміни публічного Plugin SDK і plugin-contract - включають один прохід валідації extension. - - `pnpm test:changed` маршрутизує через scope-lanes, коли змінені шляхи - можна чисто зіставити з меншим набором. + - Pre-commit hook відповідає лише за форматування. Він повторно додає відформатовані файли до stage і + не запускає lint, typecheck або тести. + - Запускайте `pnpm check:changed` явно перед передачею чи push, коли вам + потрібен розумний локальний gate. Зміни в публічному Plugin SDK і plugin-contract + включають один прохід перевірки extension. + - `pnpm test:changed` маршрутизує через scoped lanes, коли змінені шляхи + чітко відповідають меншому набору. - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, лише з вищим лімітом worker-ів. - - Автомасштабування локальних worker-ів навмисно консервативне й зменшується, + - Автоматичне масштабування локальних worker-ів навмисно консервативне й зменшується, коли середнє навантаження хоста вже високе, тому кілька одночасних запусків Vitest типово завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/конфігураційні файли як - `forceRerunTriggers`, щоб повторні запуски в changed-mode залишалися коректними, коли змінюється wiring тестів. - - Конфігурація залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете + - Базова конфігурація Vitest позначає файли projects/config як + `forceRerunTriggers`, щоб повторні запуски в режимі changed лишалися коректними, коли змінюється зв’язування тестів. + - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних + хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання. - - `pnpm test:perf:imports` вмикає звітність Vitest про тривалість імпортів, а також - вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий профілювальний перегляд - файлами, зміненими від `origin/main`. - - Коли один гарячий тест усе ще витрачає більшість часу на стартові імпорти, - тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і - напряму мокуйте цей шов замість глибоких імпортів runtime-helper-ів лише - для того, щоб передати їх через `vi.mock(...)`. + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпорту та + вивід деталізації імпортів. + - `pnpm test:perf:imports:changed` обмежує той самий вид профілювання + файлами, зміненими відносно `origin/main`. + - Коли один «гарячий» тест усе ще витрачає більшість часу на стартові імпорти, + тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і + мокайте цей seam безпосередньо замість глибокого імпорту runtime-хелперів + лише для того, щоб передати їх через `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` з нативним шляхом root project для цього зафіксованого - diff і виводить wall time плюс macOS max RSS. - - `pnpm test:perf:changed:bench -- --worktree` виконує бенчмарк поточного - брудного дерева, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. - - `pnpm test:perf:profile:main` записує профіль CPU головного потоку для - накладних витрат запуску й transform у Vitest/Vite. + `test:changed` із native root-project шляхом для цього закоміченого + diff і виводить wall time та macOS max RSS. + - `pnpm test:perf:changed:bench -- --worktree` вимірює поточне брудне дерево, + маршрутизуючи список змінених файлів через + `scripts/test-projects.mjs` і root-конфігурацію Vitest. + - `pnpm test:perf:profile:main` записує профіль CPU основного потоку для + накладних витрат запуску та transform у Vitest/Vite. - `pnpm test:perf:profile:runner` записує профілі CPU+heap runner-а для unit-набору з вимкненим файловим паралелізмом. @@ -434,36 +434,36 @@ Alias сумісності існують, щоб уникнути міграц - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker - Обсяг: - - Запускає реальний loopback Gateway з увімкненою за замовчуванням діагностикою - - Пропускає синтетичне churn повідомлень gateway, пам’яті та великих payload через шлях діагностичних подій - - Опитує `diagnostics.stability` через WS RPC Gateway - - Охоплює helper-и збереження набору діагностики стабільності - - Перевіряє, що recorder залишається обмеженим, синтетичні зразки RSS лишаються в межах бюджету тиску, а глибина черг для кожної сесії повертається до нуля + - Запускає реальний loopback Gateway з увімкненою діагностикою за замовчуванням + - Пропускає синтетичне churn повідомлень gateway, пам’яті та великих payload через діагностичний шлях подій + - Виконує запит до `diagnostics.stability` через Gateway WS RPC + - Охоплює хелпери збереження пакета діагностики стабільності + - Перевіряє, що recorder залишається обмеженим, синтетичні зразки RSS не перевищують бюджет тиску, а глибини черг для кожної сесії знову знижуються до нуля - Очікування: - Безпечно для CI і без ключів - Вузький lane для подальшої роботи над регресіями стабільності, а не заміна повного набору Gateway -### E2E (smoke Gateway) +### E2E (gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести вбудованих Plugin у `extensions/` +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled plugin у `extensions/` - Типові параметри runtime: - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивну кількість worker-ів (CI: до 2, локально: 1 за замовчуванням). - - За замовчуванням запускається в тихому режимі, щоб зменшити накладні витрати консольного I/O. + - Використовує адаптивних worker-ів (CI: до 2, локально: 1 за замовчуванням). + - За замовчуванням запускається в тихому режимі, щоб зменшити накладні витрати на console I/O. - Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` щоб примусово задати кількість worker-ів (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний консольний вивід. + - `OPENCLAW_E2E_WORKERS=` — щоб примусово задати кількість worker-ів (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` — щоб знову ввімкнути докладний вивід у консоль. - Обсяг: - - End-to-end-поведінка gateway з кількома екземплярами - - Поверхні WebSocket/HTTP, pairing Node і важча мережева взаємодія + - Наскрізна поведінка gateway з кількома інстансами + - Поверхні WebSocket/HTTP, pairинг Node і важчий мережевий стек - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні - - Більше рухомих частин, ніж у unit-тестах (може працювати повільніше) + - Більше рухомих частин, ніж у unit-тестах (може бути повільніше) -### E2E: smoke backend OpenShell +### E2E: smoke для backend OpenShell - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` @@ -471,270 +471,270 @@ Alias сумісності існують, щоб уникнути міграц - Запускає ізольований Gateway OpenShell на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - Перевіряє backend OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec - - Перевіряє remote-canonical-поведінку файлової системи через fs bridge sandbox + - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge - Очікування: - Лише opt-in; не входить до типового запуску `pnpm test:e2e` - Потребує локального CLI `openshell` і працездатного Docker daemon - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий gateway і sandbox + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує test gateway і sandbox - Корисні перевизначення: - - `OPENCLAW_E2E_OPENSHELL=1` щоб увімкнути тест при ручному запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб указати нестандартний бінарний файл CLI або wrapper-скрипт + - `OPENCLAW_E2E_OPENSHELL=1` — щоб увімкнути тест під час ручного запуску ширшого набору e2e + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` — щоб указати нестандартний бінарний файл CLI або wrapper script ### Live (реальні провайдери + реальні моделі) - Команда: `pnpm test:live` - Конфігурація: `vitest.live.config.ts` -- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести вбудованих Plugin у `extensions/` +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled plugin у `extensions/` - Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Обсяг: - - «Чи справді цей провайдер/модель _сьогодні_ працює з реальними обліковими даними?» - - Виявлення змін формату провайдера, особливостей виклику інструментів, проблем автентифікації та поведінки rate limit + - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?» + - Виявлення змін формату провайдера, особливостей виклику інструментів, проблем автентифікації та поведінки обмежень швидкості - Очікування: - - Навмисно нестабільно для CI (реальні мережі, реальні політики провайдерів, квоти, збої) - - Коштує грошей / використовує rate limit - - Краще запускати звужені підмножини, а не «все» -- Live-запуски використовують `~/.profile`, щоб підхопити відсутні API key. -- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий test home, щоб unit-фікстури не могли змінити ваш реальний `~/.openclaw`. -- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам навмисно потрібно, щоб live-тести використовували ваш реальний домашній каталог. -- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але прибирає додаткове повідомлення про `~/.profile` і заглушує bootstrap-логи gateway/шум Bonjour. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні логи запуску. -- Ротація API key (залежно від провайдера): встановіть `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або використовуйте перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спроби у відповідь на rate limit. -- Вивід прогресу/Heartbeat: - - Live-набори тепер виводять рядки прогресу в stderr, щоб довгі виклики провайдерів було видно як активні, навіть коли перехоплення консолі Vitest працює тихо. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/gateway одразу передавалися потоком під час live-запусків. - - Налаштовуйте Heartbeat для прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте Heartbeat для gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - За задумом нестабільні для CI (реальні мережі, реальні політики провайдерів, квоти, збої) + - Коштують грошей / використовують rate limits + - Переважно запускати звужені підмножини, а не «все» +- Live-запуски використовують `~/.profile`, щоб підхопити відсутні API-ключі. +- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий test home, щоб unit-fixtures не могли змінити ваш реальний `~/.openclaw`. +- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам свідомо потрібно, щоб live-тести використовували ваш реальний домашній каталог. +- `pnpm test:live` тепер за замовчуванням працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але приховує додаткове повідомлення про `~/.profile` і вимикає логи bootstrap Gateway/шум Bonjour. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете знову бачити повні стартові логи. +- Ротація API-ключів (специфічна для провайдера): установлюйте `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або перевизначення для конкретного live-запуску через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу у відповідь на rate limit. +- Вивід progress/Heartbeat: + - Live-набори тепер виводять рядки прогресу в stderr, тож довгі виклики провайдера помітно активні навіть тоді, коли Vitest працює з тихим перехопленням консолі. + - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тож рядки прогресу провайдера/Gateway передаються негайно під час live-запусків. + - Налаштовуйте Heartbeat прямої моделі через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте Heartbeat gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір запускати? +## Який набір мені запускати? -Скористайтеся цією таблицею рішень: +Використовуйте цю таблицю рішень: -- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) -- Торкаєтесь мережевої взаємодії gateway / WS protocol / pairing: додайте `pnpm test:e2e` -- Налагоджуєте «мій bot не працює» / збої провайдера / виклик інструментів: запускайте звужений `pnpm test:live` +- Редагування логіки/тестів: запускайте `pnpm test` (і `pnpm test:coverage`, якщо ви багато що змінили) +- Зміни в мережевій взаємодії gateway / WS protocol / pairing: додайте `pnpm test:e2e` +- Налагодження «мій бот не працює» / збоїв, специфічних для провайдера / виклику інструментів: запускайте звужений `pnpm test:live` -## Live-тести (які торкаються мережі) +## Live-тести (що звертаються до мережі) -Для матриці live-моделей, smoke backend CLI, smoke ACP, harness -app-server Codex і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, image, +Для live matrix моделей, smoke-тестів backend CLI, smoke-тестів ACP, harness +Codex app-server і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, image, music, video, media harness) — а також обробки облікових даних для live-запусків — див. [Тестування — live-набори](/uk/help/testing-live). -## Docker-ранери (необов’язкові перевірки «працює в Linux») +## Docker runners (необов’язкові перевірки «працює в Linux») -Ці Docker-ранери поділяються на дві групи: +Ці Docker runners поділяються на дві категорії: -- Ранери live-моделей: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний їм live-файл profile-key всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог config і робочий простір (і використовують `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoint — `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live-ранери за замовчуванням використовують менший smoke-ліміт, щоб повний Docker-обхід залишався практичним: - `test:docker:live-models` типово використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а - `test:docker:live-gateway` типово використовує `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний їхньому ключу профілю live-файл всередині Docker image репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог config і workspace (і використовують `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoint-и: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker live runners за замовчуванням мають менший smoke-ліміт, щоб повний Docker sweep залишався практичним: + `test:docker:live-models` за замовчуванням використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а + `test:docker:live-gateway` — `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` і - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли - вам навмисно потрібен більший вичерпний обхід. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, а потім повторно використовує його для Docker live-lanes. Він також збирає один спільний образ `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для container smoke-ранерів E2E, які перевіряють зібраний застосунок. Агрегатор використовує зважений локальний планувальник: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а ліміти ресурсів не дають важким live-, npm-install- і multi-service-lanes запускатися одночасно. Типові значення: 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більший запас ресурсів. -- Container smoke-ранери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env-змінні, коли + вам свідомо потрібне більше вичерпне сканування. +- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для Docker lane-ів live. Він також збирає один спільний image `scripts/e2e/Dockerfile` через `test:docker:e2e-build` і повторно використовує його для container smoke runner-ів E2E, які перевіряють зібраний застосунок. Агрегат використовує зважений локальний планувальник: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а resource caps не дають одночасно стартувати всім важким live, npm-install і multi-service lane-ам. Типові значення — 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більше запасу ресурсів. Runner за замовчуванням виконує Docker preflight, видаляє застарілі контейнери OpenClaw E2E, кожні 30 секунд виводить статус, зберігає тривалості успішних lane-ів у `.artifacts/docker-tests/lane-timings.json` і використовує ці тривалості, щоб у наступних запусках спочатку стартували довші lane-и. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести зважений маніфест lane-ів без збирання та запуску Docker. +- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:gateway-network`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Docker-ранери live-моделей також bind-mount лише потрібні home-каталоги автентифікації CLI (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени, не змінюючи сховище автентифікації на хості: +Docker runners live-model також bind-mount-ять лише потрібні CLI auth home-и (або всі підтримувані, якщо запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без змін у сховищі auth на хості: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) - Smoke ACP bind: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`) - Smoke CLI backend: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) -- Smoke harness app-server Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) +- Smoke harness Codex app-server: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) - Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер onboarding (TTY, повне scaffolding): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Smoke onboarding/channel/agent з npm tarball: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding з посиланням на env плюс Telegram за замовчуванням, перевіряє, що doctor відновлює runtime-залежності активованих Plugin, і виконує один замоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемкніть channel через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Smoke глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудовані image-провайдери замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть збірку на хості через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` зі зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Docker smoke інсталятора: `bash scripts/test-install-sh-docker.sh` використовує спільний кеш npm для своїх контейнерів root, update і direct-npm. Smoke оновлення за замовчуванням використовує npm `latest` як стабільну базову версію перед оновленням до tarball-кандидата. Перевірки інсталятора без root зберігають ізольований кеш npm, щоб записи кешу, створені root, не маскували поведінку локального встановлення користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними повторними запусками. -- Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. +- Smoke Open WebUI live: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер onboarding (TTY, повний scaffolding): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Smoke onboarding/channel/agent через npm tarball: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding з посиланням на env і за замовчуванням Telegram, перевіряє, що doctor відновлює runtime deps активованого plugin, і виконує один змоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_NPM_ONBOARD_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host rebuild через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або змініть канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Smoke глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольований home і перевіряє, що `openclaw infer image providers --json` повертає bundled image providers замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host build через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Smoke Installer у Docker: `bash scripts/test-install-sh-docker.sh` використовує спільний npm cache для своїх контейнерів root, update і direct-npm. Smoke оновлення за замовчуванням використовує npm `latest` як стабільну baseline перед оновленням до tarball кандидата. Перевірки installer без root зберігають ізольований npm cache, щоб cache entries, створені root, не маскували поведінку локального встановлення користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm у локальних повторних запусках. +- Install Smoke CI пропускає дубльований direct-npm global update через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. - Мережева взаємодія Gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Мінімальна reasoning-регресія для OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає замоканий сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово спричиняє відхилення схеми провайдера і перевіряє, що необроблена деталь з’являється в логах Gateway. -- Міст MCP channel (seeded Gateway + stdio-міст + smoke сирих notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) -- Інструменти Pi bundle MCP (реальний stdio MCP-сервер + smoke allow/deny для вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Очищення MCP Cron/subagent (реальний Gateway + завершення дочірнього stdio MCP після ізольованих запусків cron і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (smoke встановлення + alias `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) -- Smoke незміненого оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke метаданих перезавантаження config: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Runtime-залежності вбудованих Plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий образ Docker runner, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використовуйте образ через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker-агрегатор пакує цей tarball один раз, а потім розбиває перевірки вбудованих channel на незалежні lanes; використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю channel під час прямого запуску bundled-lane. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують відновлення doctor/runtime-залежностей. -- Звужуйте runtime-залежності вбудованих Plugin під час ітерації, вимикаючи не пов’язані сценарії, наприклад: +- Регресія мінімального reasoning для OpenAI Responses `web_search`: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає змоканий сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово викликає відхилення provider schema і перевіряє, що сирі деталі з’являються в логах Gateway. +- Міст MCP channel (seeded Gateway + stdio bridge + smoke сирих notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Інструменти Pi bundle MCP (реальний stdio MCP server + smoke allow/deny вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Cleanup MCP для Cron/subagent (реальний Gateway + teardown дочірнього stdio MCP після ізольованих запусків cron і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (smoke встановлення + псевдонім `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) +- Smoke незмінного оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke метаданих перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Runtime deps bundled plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий Docker image runner-а, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожний Linux-сценарій встановлення. Повторно використовуйте image через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть host rebuild після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_BUNDLED_CHANNEL_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker aggregate попередньо пакує цей tarball один раз, а потім розбиває перевірки bundled channel на незалежні lane-и, включно з окремими lane-ами оновлення для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю каналів під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити сценарій оновлення. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують відновлення doctor/runtime-dependency. +- Звужуйте runtime deps bundled plugin під час ітерації, вимикаючи не пов’язані сценарії, наприклад: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. -Щоб вручну попередньо зібрати і повторно використати спільний образ зібраного застосунку: +Щоб вручну попередньо зібрати та повторно використати спільний image built-app: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Перевизначення образів для конкретних наборів, такі як `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо його ще немає локально. Docker-тести QR та інсталятора зберігають власні Dockerfile, оскільки перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. +Перевизначення image для конкретного набору, такі як `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, якщо задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` указує на віддалений спільний image, скрипти завантажують його, якщо його ще немає локально. Docker-тести QR та installer зберігають власні Dockerfile, тому що вони перевіряють поведінку пакування/встановлення, а не спільний runtime built-app. -Docker-ранери live-моделей також монтують bind-mount поточного checkout лише для читання та -розміщують його в тимчасовому workdir усередині контейнера. Це зберігає runtime-образ -компактним, але водночас дозволяє запускати Vitest точно проти вашого локального source/config. -Крок staging пропускає великі локальні кеші й результати збірки застосунків, такі як -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні каталоги `.build` застосунків або -вивід Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання -специфічних для машини артефактів. -Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-probe Gateway не запускали -реальні worker-и channel Telegram/Discord/etc. усередині контейнера. +Docker runners live-model також bind-mount-ять поточний checkout у режимі лише для читання і +розміщують його у тимчасовому workdir усередині контейнера. Це зберігає runtime +image компактним, але все одно запускає Vitest проти ваших точних локальних source/config. +Етап розміщення пропускає великі локальні cache та результати збірки застосунків, такі як +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунків каталоги `.build` або +виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання +машинно-специфічних артефактів. +Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live probes Gateway не запускали +реальні worker-и каналів Telegram/Discord тощо всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття Gateway -з цього Docker lane. -`test:docker:openwebui` — це compatibility smoke вищого рівня: він запускає -контейнер Gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoint, -запускає pinned-контейнер Open WebUI проти цього gateway, виконує вхід через +`OPENCLAW_LIVE_GATEWAY_*`, коли вам потрібно звузити або виключити покриття gateway +live із цього Docker lane. +`test:docker:openwebui` — це smoke перевірки сумісності вищого рівня: він запускає +контейнер Gateway OpenClaw з увімкненими HTTP endpoint OpenAI-compatible, +запускає закріплений контейнер Open WebUI проти цього gateway, виконує вхід через Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає -реальний chat-запит через проксі `/api/chat/completions` Open WebUI. -Перший запуск може бути помітно повільнішим, оскільки Docker може знадобитися завантажити -образ Open WebUI, а самому Open WebUI — завершити власне cold-start-налаштування. -Цей lane очікує придатний ключ live-моделі, і `OPENCLAW_PROFILE_FILE` -(`~/.profile` за замовчуванням) — основний спосіб надати його в Dockerized-запусках. +реальний запит чату через proxy Open WebUI `/api/chat/completions`. +Перший запуск може бути помітно повільнішим, оскільки Docker може потребувати завантаження +image Open WebUI, а самому Open WebUI може знадобитися завершити власне cold-start налаштування. +Цей lane очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE` +(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized-запусках. Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він запускає seeded-контейнер Gateway, -запускає другий контейнер, який піднімає `openclaw mcp serve`, а потім -перевіряє виявлення маршрутизованих розмов, читання транскриптів, метадані вкладень, -поведінку live-черги подій, маршрутизацію надсилання outbound і сповіщення channel + -дозволів у стилі Claude через реальний stdio MCP-міст. Перевірка сповіщень -безпосередньо інспектує сирі stdio MCP-кадри, тож smoke перевіряє те, що міст -фактично випромінює, а не лише те, що випадково показує конкретний client SDK. -`test:docker:pi-bundle-mcp-tools` є детермінованим і не потребує -ключа live-моделі. Він збирає Docker-образ репозиторію, запускає реальний stdio MCP probe-сервер -усередині контейнера, матеріалізує цей сервер через runtime вбудованого Pi bundle -MCP, виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають +реального акаунта Telegram, Discord або iMessage. Він запускає seeded Gateway +container, стартує другий container, який породжує `openclaw mcp serve`, а потім +перевіряє виявлення маршрутизованої розмови, читання транскриптів, метадані вкладень, +поведінку черги live event, маршрутизацію вихідних надсилань і сповіщення у стилі Claude про channel + +permission через реальний stdio MCP bridge. Перевірка сповіщень +безпосередньо аналізує сирі stdio MCP frames, тож smoke перевіряє те, що +міст справді випромінює, а не лише те, що певний SDK клієнта випадково показує. +`test:docker:pi-bundle-mcp-tools` детермінований і не потребує +ключа live-моделі. Він збирає Docker image репозиторію, запускає реальний stdio MCP probe server +усередині контейнера, матеріалізує цей server через runtime MCP вбудованого bundle Pi, +виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. -`test:docker:cron-mcp-cleanup` є детермінованим і не потребує ключа live-моделі. -Він запускає seeded Gateway з реальним stdio MCP probe-сервером, виконує -ізольований хід cron і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, +`test:docker:cron-mcp-cleanup` детермінований і не потребує ключа live-моделі. +Він запускає seeded Gateway із реальним stdio MCP probe server, виконує +ізольований cron-хід і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, що дочірній процес MCP завершується після кожного запуску. Ручний smoke plain-language thread для ACP (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей скрипт для регресійних/налагоджувальних сценаріїв. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його. +- Зберігайте цей скрипт для сценаріїв регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його. -Корисні env vars: +Корисні змінні середовища: -- `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) монтується в `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) монтується в `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) монтується в `/home/node/.profile` і використовується перед запуском тестів -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` щоб перевіряти лише env vars, отримані з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги config/workspace і без монтування auth зовнішніх CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker -- Зовнішні каталоги/файли auth CLI в `$HOME` монтуються лише для читання в `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів +- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) монтується в `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) монтується в `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) монтується в `/home/node/.profile` і використовується перед запуском тестів +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише env vars, отримані з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги config/workspace і без монтування зовнішньої CLI auth +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI усередині Docker +- Зовнішні каталоги/файли CLI auth під `$HOME` монтуються в режимі лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед початком тестів - Типові каталоги: `.minimax` - Типові файли: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, визначені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - Перевизначайте вручну через `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або список через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` -- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` щоб звузити запуск -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` щоб фільтрувати провайдерів усередині контейнера -- `OPENCLAW_SKIP_DOCKER_BUILD=1` щоб повторно використовувати наявний образ `openclaw:local-live` для повторних запусків, яким не потрібна перебудова -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб гарантувати, що облікові дані беруться зі сховища profile (а не з env) -- `OPENCLAW_OPENWEBUI_MODEL=...` щоб вибрати модель, яку gateway показує для smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...` щоб перевизначити промпт перевірки nonce, який використовує smoke Open WebUI -- `OPENWEBUI_IMAGE=...` щоб перевизначити pinned-тег образу Open WebUI +- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, щоб звузити запуск +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб відфільтрувати провайдерів усередині контейнера +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний image `openclaw:local-live` для повторних запусків, яким не потрібна перебудова +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища profile (а не з env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway показує для smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити nonce-check prompt, який використовує smoke Open WebUI +- `OPENWEBUI_IMAGE=...`, щоб перевизначити закріплений tag image Open WebUI ## Перевірка документації Після редагування документації запускайте перевірки docs: `pnpm check:docs`. -Запускайте повну перевірку якірних посилань Mintlify, коли вам також потрібні перевірки заголовків усередині сторінки: `pnpm docs:check-links:anchors`. +Запускайте повну перевірку anchor у Mintlify, коли вам також потрібні перевірки внутрішньосторінкових heading: `pnpm docs:check-links:anchors`. ## Офлайн-регресія (безпечна для CI) Це регресії «реального pipeline» без реальних провайдерів: - Виклик інструментів Gateway (mock OpenAI, реальний gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + примусову auth token): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") +- Майстер Gateway (WS `wizard.start`/`wizard.next`, примусово записує config + auth): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") ## Оцінювання надійності агента (Skills) У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агента»: -- Mock-виклик інструментів через реальний gateway + цикл агента (`src/gateway/gateway.test.ts`). -- End-to-end-потоки майстра, які перевіряють прив’язку сесій і ефекти конфігурації (`src/gateway/gateway.test.ts`). +- Mock-виклик інструментів через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`). +- Наскрізні потоки майстра, які перевіряють прив’язку сесії та ефекти конфігурації (`src/gateway/gateway.test.ts`). -Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)): +Що ще бракує для Skills (див. [Skills](/uk/tools/skills)): -- **Вибір рішень:** коли Skills перелічені в промпті, чи вибирає агент правильний Skill (або уникає нерелевантних)? -- **Відповідність:** чи читає агент `SKILL.md` перед використанням і чи виконує обов’язкові кроки/аргументи? +- **Вибір рішення:** коли Skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? +- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи виконує обов’язкові кроки/аргументи? - **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. -Майбутні eval мають насамперед залишатися детермінованими: +Майбутні eval-и мають насамперед залишатися детермінованими: -- Runner сценаріїв, який використовує mock-провайдери для перевірки викликів інструментів і їхнього порядку, читання skill-файлів і прив’язки сесій. -- Невеликий набір сценаріїв, зосереджених на Skills (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live-eval (opt-in, із керуванням через env) лише після того, як буде готовий безпечний для CI набір. +- Runner сценаріїв, який використовує mock-провайдерів для перевірки викликів інструментів + їх порядку, читання skill-файлів і прив’язки сесії. +- Невеликий набір сценаріїв, зосереджених на skills (використати чи уникнути, gating, prompt injection). +- Необов’язкові live eval-и (opt-in, із керуванням через env) — лише після того, як з’явиться безпечний для CI набір. -## Контрактні тести (форма Plugin і channel) +## Контрактні тести (форма plugin і channel) -Контрактні тести перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму -контракту інтерфейсу. Вони проходять по всіх виявлених Plugins і запускають набір -перевірок форми та поведінки. Типовий unit-lane `pnpm test` навмисно +Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає +своєму інтерфейсному контракту. Вони проходять по всіх виявлених plugin-ах і запускають +набір перевірок форми та поведінки. Типовий unit lane `pnpm test` навмисно пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, -коли торкаєтеся спільних поверхонь channel або провайдера. +коли торкаєтеся спільних поверхонь channel або provider. ### Команди - Усі контракти: `pnpm test:contracts` - Лише контракти channel: `pnpm test:contracts:channels` -- Лише контракти провайдерів: `pnpm test:contracts:plugins` +- Лише контракти provider: `pnpm test:contracts:plugins` ### Контракти channel Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Базова форма Plugin (id, name, capabilities) -- **setup** - Контракт майстра setup +- **plugin** - Базова форма plugin (id, name, capabilities) +- **setup** - Контракт майстра налаштування - **session-binding** - Поведінка прив’язки сесії - **outbound-payload** - Структура payload повідомлення - **inbound** - Обробка вхідних повідомлень -- **actions** - Обробники дій channel +- **actions** - Обробники дій каналу - **threading** - Обробка ID thread - **directory** - API directory/roster -- **group-policy** - Примусове застосування політики груп +- **group-policy** - Застосування group policy -### Контракти статусу провайдера +### Контракти статусу provider Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Перевірки статусу channel -- **registry** - Форма реєстру Plugin +- **status** - Перевірки status каналу +- **registry** - Форма registry plugin -### Контракти провайдерів +### Контракти provider Розташовані в `src/plugins/contracts/*.contract.test.ts`: - **auth** - Контракт потоку auth -- **auth-choice** - Вибір/вибірка auth +- **auth-choice** - Вибір/селекція auth - **catalog** - API каталогу моделей -- **discovery** - Виявлення Plugin -- **loader** - Завантаження Plugin +- **discovery** - Виявлення plugin +- **loader** - Завантаження plugin - **runtime** - Runtime провайдера -- **shape** - Форма/інтерфейс Plugin -- **wizard** - Майстер setup +- **shape** - Форма/інтерфейс plugin +- **wizard** - Майстер налаштування ### Коли запускати -- Після зміни exports або subpath у plugin-sdk -- Після додавання або зміни channel чи Plugin провайдера -- Після рефакторингу реєстрації Plugin або виявлення +- Після зміни export-ів або subpath-ів plugin-sdk +- Після додавання або зміни channel чи provider plugin +- Після рефакторингу реєстрації або виявлення plugin -Контрактні тести запускаються в CI і не потребують реальних API key. +Контрактні тести запускаються в CI і не потребують реальних API-ключів. -## Додавання регресій (настанови) +## Додавання регресій (рекомендації) -Коли ви виправляєте проблему провайдера/моделі, виявлену в live: +Коли ви виправляєте проблему provider/model, виявлену в live: -- Додайте безпечну для CI регресію, якщо це можливо (mock/stub провайдера або захоплення точної трансформації форми запиту) -- Якщо проблема за своєю природою лише live (rate limit, політики auth), залишайте live-тест вузьким і opt-in через env vars -- Віддавайте перевагу націлюванню на найменший шар, який ловить помилку: - - помилка перетворення/відтворення запиту провайдера → тест прямих моделей - - помилка gateway у pipeline сесії/історії/інструментів → live smoke Gateway або безпечний для CI mock-тест Gateway -- Захисне правило обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef із метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегмента обходу відхиляються. - - Якщо ви додаєте нову сім’ю цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити. +- Додайте безпечну для CI регресію, якщо можливо (mock/stub provider або захоплення точної трансформації форми запиту) +- Якщо проблема за своєю природою лише live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars +- Переважно націлюватися на найменший рівень, який виявляє баг: + - баг конвертації/відтворення запиту провайдера → тест прямих моделей + - баг pipeline сесії/історії/інструментів gateway → live smoke gateway або безпечний для CI mock-тест gateway +- Захист traversal для SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль на клас SecretRef із метаданих registry (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегментів traversal відхиляються. + - Якщо ви додаєте нове сімейство цілей SecretRef з `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було пропустити мовчки. ## Пов’язане -- [Live-тестування](/uk/help/testing-live) +- [Testing live](/uk/help/testing-live) - [CI](/uk/ci) diff --git a/docs/uk/providers/github-copilot.md b/docs/uk/providers/github-copilot.md index d7274249e..0d33a2f8b 100644 --- a/docs/uk/providers/github-copilot.md +++ b/docs/uk/providers/github-copilot.md @@ -1,29 +1,25 @@ --- read_when: - - Ви хочете використовувати GitHub Copilot як провайдера models - - Вам потрібен потік `openclaw models auth login-github-copilot` -summary: Увійти до GitHub Copilot з OpenClaw за допомогою device flow + - Ви хочете використовувати GitHub Copilot як постачальника моделі + - Вам потрібен процес `openclaw models auth login-github-copilot` +summary: Увійдіть у GitHub Copilot з OpenClaw за допомогою device flow title: GitHub Copilot x-i18n: - generated_at: "2026-04-23T21:06:03Z" + generated_at: "2026-04-24T22:51:39Z" model: gpt-5.4 provider: openai - source_hash: 8b54a063e30e9202c6b9de35a1a3736ef8c36020296215491fb719afe73a0c3e + source_hash: d21ef936578741fe458f50ca25034a71e4571ae1e873de5e6d71138a950f5d70 source_path: providers/github-copilot.md workflow: 15 --- -GitHub Copilot — це AI-помічник для кодування від GitHub. Він надає доступ до -моделей Copilot для вашого облікового запису та плану GitHub. OpenClaw може -використовувати Copilot як провайдера models двома різними способами. +GitHub Copilot — це помічник для кодування зі штучним інтелектом від GitHub. Він надає доступ до моделей Copilot для вашого облікового запису GitHub і тарифного плану. OpenClaw може використовувати Copilot як постачальника моделі двома різними способами. ## Два способи використовувати Copilot в OpenClaw - - Використовуйте нативний device-login flow, щоб отримати токен GitHub, а потім обмінювати його на - API-токени Copilot під час роботи OpenClaw. Це **типовий** і найпростіший шлях, - оскільки він не потребує VS Code. + + Використовуйте нативний процес входу через device flow, щоб отримати токен GitHub, а потім обміняти його на токени API Copilot під час роботи OpenClaw. Це **типовий** і найпростіший шлях, оскільки він не потребує VS Code. @@ -31,15 +27,14 @@ GitHub Copilot — це AI-помічник для кодування від Git openclaw models auth login-github-copilot ``` - Вам буде запропоновано перейти за URL і ввести одноразовий код. Не закривайте - термінал до завершення процесу. + Вам буде запропоновано перейти за URL-адресою та ввести одноразовий код. Тримайте термінал відкритим, доки процес не завершиться. - + ```bash openclaw models set github-copilot/claude-opus-4.7 ``` - Або в config: + Або в конфігурації: ```json5 { @@ -54,12 +49,10 @@ GitHub Copilot — це AI-помічник для кодування від Git - Використовуйте розширення **Copilot Proxy** для VS Code як локальний bridge. OpenClaw звертається до - ендпоінта `/v1` цього proxy і використовує список моделей, який ви там налаштуєте. + Використовуйте розширення VS Code **Copilot Proxy** як локальний міст. OpenClaw звертається до endpoint `/v1` проксі та використовує список моделей, який ви там налаштовуєте. - Обирайте це, якщо ви вже використовуєте Copilot Proxy у VS Code або вам потрібно маршрутизувати - через нього. Ви маєте ввімкнути plugin і підтримувати роботу розширення VS Code. + Вибирайте цей варіант, якщо ви вже запускаєте Copilot Proxy у VS Code або вам потрібно маршрутизувати трафік через нього. Ви маєте ввімкнути Plugin і підтримувати роботу розширення VS Code. @@ -69,76 +62,71 @@ GitHub Copilot — це AI-помічник для кодування від Git | Прапорець | Опис | | -------------- | --------------------------------------------------- | -| `--yes` | Пропустити запит підтвердження | -| `--set-default` | Також застосувати рекомендовану типову модель провайдера | +| `--yes` | Пропустити запит на підтвердження | +| `--set-default` | Також застосувати рекомендовану типову модель постачальника | ```bash -# Skip confirmation +# Пропустити підтвердження openclaw models auth login-github-copilot --yes -# Login and set the default model in one step +# Увійти та встановити типову модель за один крок openclaw models auth login --provider github-copilot --method device --set-default ``` - Device-login flow потребує інтерактивного TTY. Запускайте його безпосередньо в - терміналі, а не в неінтерактивному скрипті чи CI pipeline. + Процес входу через device flow вимагає інтерактивного TTY. Запускайте його безпосередньо в терміналі, а не в неінтерактивному скрипті чи CI-конвеєрі. - - Доступність моделей Copilot залежить від вашого плану GitHub. Якщо модель - відхиляється, спробуйте інший ID (наприклад, `github-copilot/gpt-4.1`). + + Доступність моделей Copilot залежить від вашого тарифного плану GitHub. Якщо модель відхиляється, спробуйте інший ідентифікатор (наприклад, `github-copilot/gpt-4.1`). - - ID моделей Claude автоматично використовують transport Anthropic Messages. Моделі GPT, - o-series і Gemini залишають OpenAI Responses transport. OpenClaw - вибирає правильний transport на основі model ref. + + Ідентифікатори моделей Claude автоматично використовують транспорт Anthropic Messages. Моделі GPT, o-series і Gemini зберігають транспорт OpenAI Responses. OpenClaw вибирає правильний транспорт на основі посилання на модель. - - OpenClaw розв’язує auth Copilot зі змінних середовища в такому - порядку пріоритету: + + OpenClaw надсилає для транспортів Copilot заголовки запитів у стилі Copilot IDE, включно з подальшими ходами tool-result і image. Він не вмикає continuation Responses на рівні постачальника для Copilot, якщо таку поведінку не було перевірено на API Copilot. + + + + OpenClaw визначає автентифікацію Copilot зі змінних середовища в такому порядку пріоритету: | Пріоритет | Змінна | Примітки | | --------- | -------------------- | -------------------------------- | - | 1 | `COPILOT_GITHUB_TOKEN` | Найвищий пріоритет, специфічний для Copilot | + | 1 | `COPILOT_GITHUB_TOKEN` | Найвищий пріоритет, специфічна для Copilot | | 2 | `GH_TOKEN` | Токен GitHub CLI (резервний варіант) | - | 3 | `GITHUB_TOKEN` | Стандартний токен GitHub (найнижчий) | + | 3 | `GITHUB_TOKEN` | Стандартний токен GitHub (найнижчий пріоритет) | - Коли задано кілька змінних, OpenClaw використовує ту, що має найвищий пріоритет. - Device-login flow (`openclaw models auth login-github-copilot`) зберігає - свій токен у сховищі auth profile і має пріоритет над усіма змінними - середовища. + Коли встановлено кілька змінних, OpenClaw використовує ту, що має найвищий пріоритет. + Процес входу через device flow (`openclaw models auth login-github-copilot`) зберігає свій токен у сховищі профілів автентифікації та має пріоритет над усіма змінними середовища. - Під час входу токен GitHub зберігається в сховищі auth profile, а вже під час запуску OpenClaw він обмінюється - на API-токен Copilot. Вам не потрібно керувати токеном вручну. + Під час входу токен GitHub зберігається у сховищі профілів автентифікації та обмінюється на токен API Copilot під час роботи OpenClaw. Вам не потрібно керувати токеном вручну. -Потрібен інтерактивний TTY. Запускайте команду входу безпосередньо в терміналі, а не -в headless-скрипті чи CI job. +Потрібен інтерактивний TTY. Запускайте команду входу безпосередньо в терміналі, а не всередині headless-скрипту чи CI-завдання. -## Embeddings для пошуку пам’яті +## Вбудовування для пошуку в пам’яті -GitHub Copilot також може слугувати провайдером embeddings для -[пошуку пам’яті](/uk/concepts/memory-search). Якщо у вас є підписка Copilot і -ви вже увійшли в систему, OpenClaw може використовувати його для embeddings без окремого API-ключа. +GitHub Copilot також може слугувати постачальником вбудовувань для +[пошуку в пам’яті](/uk/concepts/memory-search). Якщо у вас є підписка Copilot і +ви виконали вхід, OpenClaw може використовувати його для вбудовувань без окремого API-ключа. -### Автовизначення +### Автовиявлення -Коли `memorySearch.provider` має значення `"auto"` (типове), GitHub Copilot пробується -з пріоритетом 15 — після локальних embeddings, але до OpenAI та інших платних -провайдерів. Якщо доступний токен GitHub, OpenClaw виявляє доступні -embedding-моделі через API Copilot і автоматично вибирає найкращу. +Коли `memorySearch.provider` має значення `"auto"` (типове значення), GitHub Copilot +пробується з пріоритетом 15 — після локальних вбудовувань, але перед OpenAI та іншими платними +постачальниками. Якщо доступний токен GitHub, OpenClaw виявляє доступні +моделі вбудовувань через API Copilot і автоматично вибирає найкращу. -### Явна config +### Явна конфігурація ```json5 { @@ -146,7 +134,7 @@ embedding-моделі через API Copilot і автоматично виби defaults: { memorySearch: { provider: "github-copilot", - // Optional: override the auto-discovered model + // Необов’язково: перевизначити модель, виявлену автоматично model: "text-embedding-3-small", }, }, @@ -156,22 +144,22 @@ embedding-моделі через API Copilot і автоматично виби ### Як це працює -1. OpenClaw розв’язує ваш токен GitHub (зі змінних env або auth profile). -2. Обмінює його на короткоживучий API-токен Copilot. -3. Опитує ендпоінт Copilot `/models`, щоб виявити доступні embedding-моделі. +1. OpenClaw визначає ваш токен GitHub (зі змінних середовища або профілю автентифікації). +2. Обмінює його на короткоживучий токен API Copilot. +3. Виконує запит до endpoint `/models` Copilot, щоб виявити доступні моделі вбудовувань. 4. Вибирає найкращу модель (надає перевагу `text-embedding-3-small`). -5. Надсилає запити на embeddings до ендпоінта Copilot `/embeddings`. +5. Надсилає запити на вбудовування до endpoint `/embeddings` Copilot. -Доступність моделей залежить від вашого плану GitHub. Якщо embedding-моделей -немає, OpenClaw пропускає Copilot і пробує наступного провайдера. +Доступність моделей залежить від вашого тарифного плану GitHub. Якщо моделі +вбудовувань недоступні, OpenClaw пропускає Copilot і переходить до наступного постачальника. ## Пов’язане - Вибір провайдерів, посилань на моделі та поведінки failover. + Вибір постачальників, посилань на моделі та поведінки резервного перемикання. - - Деталі auth і правила повторного використання credentials. + + Докладніше про автентифікацію та правила повторного використання облікових даних. diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index 494b9890c..c2163158d 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -4,48 +4,48 @@ read_when: summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage title: Тести x-i18n: - generated_at: "2026-04-24T19:52:49Z" + generated_at: "2026-04-24T22:51:37Z" model: gpt-5.4 provider: openai - source_hash: 4393562f7ab8471d44ab1573bc14b041fb50058bfc61de628e02328793193ed7 + source_hash: f15e68a95d68dd076862aa168a836c4918876afa1f925ed183f7fde8ec75f24a source_path: reference/test.md workflow: 15 --- -- Повний набір для тестування (набори, live, Docker): [Testing](/uk/help/testing) +- Повний набір для тестування (сьюти, live, Docker): [Тестування](/uk/help/testing) -- `pnpm test:force`: завершує будь-який завислий процес gateway, що утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789. -- `pnpm test:coverage`: запускає unit-набір із V8 coverage (через `vitest.unit.config.ts`). Це перевірка unit coverage для завантажених файлів, а не coverage всіх файлів у всьому репозиторії. Пороги становлять 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 Vitest lane-и, коли diff зачіпає лише routable файли вихідного коду/тестів. Зміни config/setup, як і раніше, повертаються до нативного запуску root projects, щоб зміни в wiring за потреби повторно запускали ширший набір. -- `pnpm changed:lanes`: показує архітектурні lane-и, активовані diff-ом відносно `origin/main`. -- `pnpm check:changed`: запускає розумну перевірку changed gate для diff-а відносно `origin/main`. Вона запускає core-роботи з core test lane-ами, роботу extensions — з extension test lane-ами, зміни лише в тестах — тільки з test typecheck/tests, розширює зміни в публічному SDK Plugin-ів або plugin-contract до одного проходу валідації extensions і залишає version bumps лише в release metadata на цільових перевірках version/config/root-dependency. -- `pnpm test`: маршрутизує явні цілі file/directory через scoped Vitest lane-и. Запуски без цілі використовують фіксовані shard-групи та розгортаються до leaf config-ів для локального паралельного виконання; група extensions завжди розгортається до shard config-ів для кожного 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-ах. -- Вибрані файли вихідного коду helper-ів `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, тож невеликі правки helper-ів не спричиняють повторного запуску важких наборів із підтримкою runtime. -- `auto-reply` тепер також розділено на три окремі config-и (`core`, `top-level`, `reply`), тож harness reply не домінує над легшими тестами top-level status/token/helper. -- Базовий config Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний non-isolated runner увімкнено в config-ах репозиторію. +- `pnpm test:force`: Завершує будь-який завислий процес gateway, який утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789. +- `pnpm test:coverage`: Запускає набір unit-тестів з V8 coverage (через `vitest.unit.config.ts`). Це перевірка unit coverage для завантажених файлів, а не coverage всіх файлів у всьому репозиторії. Порогові значення: 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 зачіпає лише routable файли коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску root project, щоб за потреби правки wiring перезапускали ширший набір. +- `pnpm changed:lanes`: показує архітектурні lane, які запускаються diff відносно `origin/main`. +- `pnpm check:changed`: запускає розумну changed-перевірку для diff відносно `origin/main`. Вона запускає core-роботи з lane core-тестів, extension-роботи з lane extension-тестів, test-only зміни лише з test typecheck/tests, розширює зміни публічного Plugin SDK або plugin-contract до одного проходу валідації extension і залишає підвищення версій лише в release metadata на цільових перевірках version/config/root-dependency. +- `pnpm test`: маршрутизує явні цілі файлів/каталогів через scoped lane Vitest. Запуски без цілей використовують фіксовані shard-групи та розгортаються до leaf configs для локального паралельного виконання; група extension завжди розгортається до per-extension shard config, а не до одного великого процесу 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` тепер також розбивається на три окремі config (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper. +- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнений у всіх конфігураціях репозиторію. - `pnpm test:channels` запускає `vitest.channels.config.ts`. -- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard-и extensions/Plugin-ів. Важкі channel Plugin-и, browser Plugin і OpenAI запускаються як окремі shard-и; інші групи Plugin-ів залишаються пакетованими. Використовуйте `pnpm test extensions/` для одного lane вбудованого Plugin-а. -- `pnpm test:perf:imports`: вмикає звітність Vitest про import-duration + import-breakdown, водночас зберігаючи scoped lane routing для явних цілей file/directory. -- `pnpm test:perf:imports:changed`: те саме профілювання import-ів, але лише для файлів, змінених відносно `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` виконує benchmark маршрутизованого шляху в режимі changed проти нативного запуску root-project для того самого закоміченого git diff-а. +- `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 для явних цілей файлів/каталогів. +- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`. +- `pnpm test:perf:changed:bench -- --ref ` виконує benchmark маршрутизованого шляху changed-mode проти нативного запуску 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:perf:profile:runner`: записує CPU + heap profiles для 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-а. Агент продуктивності тестів використовує це як базову лінію перед спробами виправити повільні тести. -- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після зміни, зосередженої на продуктивності. -- Інтеграція Gateway: opt-in через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. -- `pnpm test:e2e`: запускає smoke-тести gateway end-to-end (multi-instance WS/HTTP/node pairing). Типово використовує `threads` + `isolate: false` з адаптивними worker-ами у `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`: один раз збирає спільний image для live-тестів і Docker E2E image, а потім запускає Docker smoke lane-и з `OPENCLAW_SKIP_DOCKER_BUILD=1` через weighted scheduler. `OPENCLAW_DOCKER_ALL_PARALLELISM=` керує слотами процесів і типово дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` керує tail pool, чутливим до провайдерів, і також типово дорівнює 10. Обмеження важких lane-ів типово становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; для потужніших хостів використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`. Запуски lane-ів за замовчуванням зсуваються на 2 секунди, щоб уникнути локальних піків створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=`. Runner припиняє планувати нові pooled lane-и після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожен lane має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Логи для кожного lane-а записуються в `.artifacts/docker-tests//`. -- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім виконує реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live model (наприклад, OpenAI у `~/.profile`), завантажує зовнішній image Open WebUI і не очікується як CI-стабільний, на відміну від звичайних unit/e2e наборів. -- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із початковим наповненням і другий контейнер клієнта, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутованих розмов, читання транскриптів, метадані вкладень, поведінку черги live events, маршрутизацію вихідних надсилань і сповіщення про канал + дозволи в стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-кадри напряму, щоб smoke-тест відображав те, що міст реально надсилає. +- `pnpm test:perf:profile:runner`: записує CPU + heap profiles для 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. Агент продуктивності тестів використовує це як базову лінію перед спробами виправлення повільних тестів. +- `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 (pairing кількох екземплярів WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю worker у `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 lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` через зважений планувальник. `OPENCLAW_DOCKER_ALL_PARALLELISM=` керує кількістю слотів процесів і за замовчуванням дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=` керує чутливим до провайдера tail pool і за замовчуванням теж дорівнює 10. Обмеження для важких lane за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` для більших хостів. Запуски lane за замовчуванням відтерміновуються на 2 секунди, щоб уникати локальних сплесків створення контейнерів у Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=`. Runner за замовчуванням виконує попередню перевірку Docker, очищує застарілі контейнери OpenClaw E2E, виводить статус активних lane кожні 30 секунд і зберігає таймінги 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`, щоб вимкнути повторне використання таймінгів. Runner припиняє планувати нові pooled lane після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожна lane має резервний timeout у 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; окремі live/tail lane використовують жорсткіші ліміти для кожної lane. Логи для кожної lane записуються в `.artifacts/docker-tests//`. +- `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 discovery розмов, читання transcript, metadata вкладень, поведінку live event queue, маршрутизацію outbound send і сповіщення каналу + дозволів у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає необроблені stdio MCP frames безпосередньо, щоб smoke відображав те, що міст реально надсилає. -## Локальний PR gate +## Локальна PR-перевірка -Для локальних перевірок перед приземленням PR/gate запускайте: +Для локальних перевірок перед злиттям/гейтом PR запустіть: - `pnpm check:changed` - `pnpm check` @@ -54,12 +54,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` -## Benchmark затримки моделей (локальні ключі) +## Benchmark затримки моделі (локальні ключі) Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts) @@ -67,7 +67,7 @@ x-i18n: - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10` - Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY` -- Типова підказка: “Reply with a single word: ok. No punctuation or extra text.” +- Типовий prompt: “Reply with a single word: ok. No punctuation or extra text.” Останній запуск (2025-12-31, 20 запусків): @@ -95,31 +95,31 @@ 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 profiles для кожного запуску, тому захоплення таймінгів і profiles використовує той самий harness. +Вивід включає `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення максимального 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` оновлює fixture baseline, що зберігається в репозиторії, у `test/fixtures/cli-startup-bench.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` -- Порівняння поточних результатів із fixture через `pnpm test:startup:bench:check` +- Оновіть через `pnpm test:startup:bench:update` +- Порівняйте поточні результати з fixture через `pnpm test:startup:bench:check` -## Onboarding E2E (Docker) +## E2E онбордингу (Docker) -Docker необов’язковий; це потрібно лише для containerized smoke-тестів onboarding. +Docker необов’язковий; це потрібно лише для containerized smoke-тестів онбордингу. -Повний cold-start flow у чистому Linux-контейнері: +Повний потік cold-start у чистому Linux-контейнері: ```bash scripts/e2e/onboard-docker.sh @@ -127,9 +127,9 @@ scripts/e2e/onboard-docker.sh Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, а потім запускає gateway і виконує `openclaw health`. -## Smoke-тест імпорту QR (Docker) +## Smoke для QR import (Docker) -Гарантує, що підтримуваний runtime helper для QR завантажується в підтримуваних Docker Node runtime-ах (Node 24 за замовчуванням, Node 22 сумісний): +Переконується, що підтримуваний helper runtime для QR завантажується в підтримуваних Node runtime у Docker (Node 24 за замовчуванням, Node 22 сумісний): ```bash pnpm test:docker:qr @@ -137,5 +137,5 @@ pnpm test:docker:qr ## Пов’язане -- [Testing](/uk/help/testing) -- [Testing live](/uk/help/testing-live) +- [Тестування](/uk/help/testing) +- [Live-тестування](/uk/help/testing-live)