diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 0e76f87e0..93c8edab1 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,94 +1,94 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося - - Ви налагоджуєте перевірку GitHub Actions, яка завершується помилкою + - Потрібно зрозуміти, чому завдання CI виконалося або не виконалося + - Ви налагоджуєте перевірку GitHub Actions, яка не проходить - Ви координуєте запуск або повторний запуск валідації релізу - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub -summary: Граф завдань CI, гейти області дії, релізні парасольки та локальні еквіваленти команд -title: CI-конвеєр +summary: Граф завдань CI, гейти області дії, парасольки релізів і локальні еквіваленти команд +title: Конвеєр CI x-i18n: - generated_at: "2026-05-03T13:15:33Z" + generated_at: "2026-05-04T04:57:53Z" model: gpt-5.5 provider: openai - source_hash: e07fc44aa844cb66ce529c570cbbbbf502a61bcbcbc3d9488557abb459ef7678 + source_hash: 72959d0feaf1339f01c9da263153fd89cc4727da6f928933819931991222714d source_path: ci.md workflow: 16 --- -OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінилися лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний граф для release candidate і широкої валідації. Лінії Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізів міститься в окремому workflow [`Попередній випуск Plugin`](#plugin-prerelease) і запускається лише з [`Повної валідації релізу`](#full-release-validation) або явного ручного dispatch. +OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі напрями, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають увесь граф для release candidate і широкої валідації. Android-напрями залишаються опційними через `include_android`. Покриття plugin лише для релізів живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch. -## Огляд конвеєра +## Огляд pipeline | Завдання | Призначення | Коли запускається | | -------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в документації, змінені області, змінені extensions і будує маніфест CI | Завжди для non-draft push і PR | +| `preflight` | Виявляє зміни лише в docs, змінені області, змінені extensions і будує маніфест CI | Завжди для non-draft push і PR | | `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди для non-draft push і PR | -| `security-fast` | Обов’язковий агрегат для швидких security-завдань | Завжди для non-draft push і PR | -| `check-dependencies` | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node | -| `build-artifacts` | Збирання `dist/`, Control UI, перевірки зібраних артефактів і багаторазових downstream-артефактів | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Sharded-перевірки контрактів каналів зі стабільним aggregate check result | Зміни, релевантні для Node | -| `checks-node-core-test` | Шарди тестів Core Node, крім ліній channel, bundled, contract і extension | Зміни, релевантні для Node | -| `check` | Sharded-еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Архітектура, sharded boundary/prompt drift, extension guards, package boundary і gateway watch | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI та startup-memory smoke | Зміни, релевантні для Node | -| `checks` | Верифікатор для тестів каналів зібраних артефактів | Зміни, релевантні для Node | -| `checks-node-compat-node22` | Лінія збирання й smoke для сумісності з Node 22 | Ручний dispatch CI для релізів | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено | -| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills | -| `checks-windows` | Windows-специфічні тести процесів/шляхів плюс регресії shared runtime import specifier | Зміни, релевантні для Windows | -| `macos-node` | Лінія тестів TypeScript для macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Android unit tests для обох flavor плюс одне збирання debug APK | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний dispatch | -| `openclaw-performance` | Щоденні/on-demand звіти продуктивності Kova runtime з mock-provider, deep-profile і GPT 5.4 live lanes | Запланований і ручний dispatch | +| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди для non-draft push і PR | +| `security-fast` | Обов’язковий aggregate для швидких security-завдань | Завжди для non-draft push і PR | +| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist невикористаних файлів | Node-релевантні зміни | +| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built artifacts і reusable downstream artifacts | Node-релевантні зміни | +| `checks-fast-core` | Швидкі Linux-напрями коректності, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни | +| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result | Node-релевантні зміни | +| `checks-node-core-test` | Shards тестів Core Node, крім channel, bundled, contract і extension напрямів | Node-релевантні зміни | +| `check` | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни | +| `check-additional` | Architecture, sharded boundary/prompt drift, extension guards, package boundary і gateway watch | Node-релевантні зміни | +| `build-smoke` | Smoke-тести built-CLI і startup-memory smoke | Node-релевантні зміни | +| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни | +| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke-напрям | Ручний CI dispatch для релізів | +| `check-docs` | Форматування docs, lint і перевірки broken links | Docs змінено | +| `skills-python` | Ruff + pytest для Skills на Python | Python-skill-релевантні зміни | +| `checks-windows` | Windows-специфічні тести process/path плюс спільні регресії runtime import specifier | Windows-релевантні зміни | +| `macos-node` | macOS TypeScript test lane з використанням спільних built artifacts | macOS-релевантні зміни | +| `macos-swift` | Swift lint, build і tests для macOS app | macOS-релевантні зміни | +| `android` | Android unit tests для обох flavors плюс одна збірка debug APK | Android-релевантні зміни | +| `test-performance-agent` | Щоденна Codex оптимізація повільних тестів після trusted activity | Main CI success або manual dispatch | +| `openclaw-performance` | Щоденні/on-demand звіти продуктивності runtime Kova з mock-provider, deep-profile і GPT 5.4 live lanes | Scheduled і manual dispatch | ## Порядок 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 jobs. -3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати, щойно спільний build готовий. -4. Важчі platform і runtime лінії розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які напрями взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` падають швидко, не чекаючи на важчі завдання artifacts і platform matrix. +3. `build-artifacts` виконується паралельно зі швидкими Linux-напрямами, щоб downstream consumers могли стартувати одразу, щойно спільна збірка готова. +4. Важчі platform і runtime напрями розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні помилки shard, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний ключ concurrency CI версіонований (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може безстроково блокувати новіші main-запуски. Ручні full-suite-запуски використовують `CI-manual-v1-*` і не скасовують поточні запуски. +GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI-шумом, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже витіснено. Автоматичний concurrency key CI має версію (`CI-v7-*`), тож GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують runs, що вже виконуються. ## Область і маршрутизація -Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area. +Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася. -- **Редагування CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. -- **CI routing-only edits, вибрані cheap core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які fast task вправляє напряму. -- **Windows Node checks** обмежені Windows-специфічними process/path wrappers, npm/pnpm/UI runner helpers, package manager config і поверхнями CI workflow, які виконують цю лінію; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lanes. +- **Зміни CI workflow** валідовують Node CI graph плюс workflow linting, але самі по собі не примушують запускати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. +- **CI routing-only edits, selected cheap core-test fixture edits і narrow plugin contract helper/test-routing edits** використовують fast Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task безпосередньо перевіряє. +- **Windows Node checks** scoped до Windows-специфічних process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes. -Найповільніші сімейства Node tests розділені або збалансовані, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, core unit fast/support lanes запускаються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділені між chat/auth/model/http-plugin/runtime/startup lanes замість очікування built artifacts. Широкі browser, QA, media та miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries з використанням назви CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено по чотирьох matrix shards, кожен запускає вибрані незалежні guards паралельно й друкує per-check timings, зокрема `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift було прив’язано до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані. +Найповільніші сімейства Node test розділено або збалансовано, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts запускаються як три weighted shards, core unit fast/support lanes запускаються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділено між chat/auth/model/http-plugin/runtime/startup lanes замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено смугами на чотири matrix shards, кожен із яких паралельно запускає selected independent guards і друкує per-check timings, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з SMS/call-log BuildConfig flags, уникаючи дублювання debug APK packaging job під час кожного Android-relevant push. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane усе одно компілює flavor з SMS/call-log BuildConfig flags, уникаючи дублювання debug APK packaging job під час кожного Android-релевантного push. -Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на найновішій версії Knip, із вимкненим мінімальним release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати. +Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, зберігаючи при цьому intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може розв’язати статично. ## Пересилання активності ClawSweeper -`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge від активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає недовірений код pull request. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatch компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. +`.github/workflows/clawsweeper-dispatch.yml` — це target-side bridge від активності repository OpenClaw до ClawSweeper. Він не checkout і не виконує untrusted pull request code. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім надсилає компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. -Workflow має чотири лінії: +Workflow має чотири напрями: -- `clawsweeper_item` для точних запитів review issue і pull request; -- `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue; -- `clawsweeper_commit_review` для запитів review на рівні commit у push до `main`; -- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може перевірити. +- `clawsweeper_item` для точних issue і pull request review requests; +- `clawsweeper_comment` для явних команд ClawSweeper у issue comments; +- `clawsweeper_commit_review` для commit-level review requests на push до `main`; +- `github_activity` для загальної GitHub activity, яку агент ClawSweeper може inspect. -Лінія `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, коли вони наявні. Вона навмисно уникає пересилання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує normalized event до OpenClaw Gateway hook для агента ClawSweeper. +Lane `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони наявні. Він навмисно не пересилає повне webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який надсилає normalized event до OpenClaw Gateway hook для агента ClawSweeper. -Загальна активність є спостереженням, а не доставкою за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, ризиковою або операційно корисною. Рутинні opens, edits, bot churn, duplicate webhook noise і звичайний review traffic мають давати `NO_REPLY`. +Загальна активність — це спостереження, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають приводити до `NO_REPLY`. -Вважайте GitHub titles, comments, bodies, review text, branch names і commit messages недовіреними даними на всьому цьому шляху. Це input для summarization і triage, а не instructions для workflow або agent runtime. +Сприймайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data на всьому цьому шляху. Це input для summarization і triage, а не інструкції для workflow або agent runtime. ## Ручні dispatches -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна release-парасолька вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, release-only shard `agentic-plugins`, повний пакетний sweep extension і передрелізні Docker lanes Plugin вилучено з CI. Передрелізний набір Docker виконується лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. +Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Автономні ручні запуски CI виконують лише Android із `include_android=true`; повна release umbrella вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, релізний шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes для передрелізу Plugin виключені з CI. Набір Docker-перевірок передрелізу запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. -Ручні запуски використовують унікальну concurrency group, тому повний набір release-candidate не скасовується іншим push або PR-запуском на тому самому ref. Необов’язковий input `target_ref` дає довіреному виклику змогу виконати цей граф для branch, tag або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref. +Ручні запуски використовують унікальну групу concurrency, щоб повний набір release-candidate не скасовувався іншим push або PR-запуском на тому самому ref. Необов’язковий input `target_ref` дає змогу довіреному викликачеві запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -98,15 +98,15 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Ранери -| Ранер | Завдання | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, шардовані channel contract checks, `check` shards, крім lint, `check-additional` shards і aggregates, верифікатори Node test aggregate, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі для 32-vCPU коштував більше, ніж заощаджував) | -| `blacksmith-16vcpu-windows-2025` | `checks-windows` | +| Ранер | Завдання | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/bundled, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `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`; forks повертаються до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | ## Локальні еквіваленти @@ -137,7 +137,7 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso ## Продуктивність OpenClaw -`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він виконується щодня на `main`, і його можна запустити вручну: +`OpenClaw Performance` — це workflow продуктивності продукту/середовища виконання. Він щодня запускається на `main` і може запускатися вручну: ```bash gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3 @@ -145,29 +145,29 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3 ``` -Ручний dispatch зазвичай бенчмаркить workflow ref. Установіть `target_ref`, щоб бенчмаркити release tag або іншу branch з поточною реалізацією workflow. Опубліковані шляхи звітів і latest pointers ключуються за протестованим ref, а кожен `index.md` записує протестований ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters. +Ручний dispatch зазвичай benchmark-ить workflow ref. Установіть `target_ref`, щоб benchmark-ити релізний тег або іншу гілку з поточною реалізацією workflow. Опубліковані шляхи звітів і latest pointers індексуються за протестованим ref, а кожен `index.md` записує протестовані ref/SHA, workflow ref/SHA, Kova ref, profile, режим автентифікації lane, модель, кількість повторів і фільтри сценаріїв. -Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` за pinned input `kova_ref`, а потім виконує три lanes: +Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` на pinned input `kova_ref`, а потім запускає три lanes: -- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фіктивною OpenAI-compatible auth. -- `mock-deep-profile`: CPU/heap/trace profiling для startup, gateway і hotspots agent-turn. +- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фальшивою OpenAI-compatible автентифікацією. +- `mock-deep-profile`: профілювання CPU/heap/trace для startup, gateway і hotspots agent-turn. - `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний. -Lane mock-provider також виконує OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для default, hook і 50-plugin startup cases; повторювані mock-OpenAI loops `channel-chat-baseline` hello; а також CLI startup commands проти запущеного gateway. Markdown summary source probe розміщено в `source/index.md` у report bundle, поруч із raw JSON. +Lane mock-provider також запускає нативні для OpenClaw source probes після проходу Kova: вимірювання часу завантаження Gateway і пам’яті для випадків запуску default, hook і 50-plugin; повторювані mock-OpenAI hello-цикли `channel-chat-baseline`; і команди запуску CLI проти завантаженого Gateway. Markdown-зведення source probe міститься в `source/index.md` у bundle звіту, поруч із raw JSON. -Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts у `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний tested-ref pointer записується як `openclaw-performance//latest-.json`. +Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний pointer tested-ref записується як `openclaw-performance//latest-.json`. ## Повна валідація релізу -`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає branch, tag або повний commit SHA, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для release-only proof Plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm package. +`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` із цією ціллю, запускає `Plugin Prerelease` для релізних доказів plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму lane пакета Telegram проти опублікованого npm-пакета. -Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для -матриці stage, точних назв workflow jobs, відмінностей profile, artifacts і +Див. [Повна валідація релізу](/uk/reference/full-release-validation) для +матриці етапів, точних назв завдань workflow, відмінностей profile, artifacts і focused rerun handles. `OpenClaw Release Publish` — це ручний mutating release workflow. Запускайте його -з `release/YYYY.M.D` або `main` після створення release tag і після успішного -OpenClaw npm preflight. Він перевіряє `pnpm plugins:sync:check`, +з `release/YYYY.M.D` або `main` після того, як релізний тег існує, і після того, +як preflight OpenClaw npm успішно завершився. Він перевіряє `pnpm plugins:sync:check`, запускає `Plugin NPM Release` для всіх publishable plugin packages, запускає `Plugin ClawHub Release` для того самого release SHA і лише потім запускає `OpenClaw NPM Release` зі збереженим `preflight_run_id`. @@ -180,45 +180,41 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Для доказу pinned commit на branch, що швидко змінюється, використовуйте helper замість +Для pinned commit proof на гілці, що швидко рухається, використовуйте helper замість `gh workflow run ... --ref main -f ref=`: ```bash pnpm ci:full-release --sha ``` -GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. Helper -пушить тимчасову branch `release-ci/-...` на target SHA, -запускає `Full Release Validation` з цього pinned ref, перевіряє, що `headSha` кожного child -workflow збігається з target, і видаляє тимчасову branch після завершення -запуску. Umbrella verifier також завершується помилкою, якщо будь-який child workflow виконувався на +GitHub workflow dispatch refs мають бути гілками або тегами, а не raw commit SHAs. Helper +пушить тимчасову гілку `release-ci/-...` на цільовому SHA, +запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен дочірній +workflow `headSha` відповідає цілі, і видаляє тимчасову гілку після завершення +запуску. Umbrella verifier також падає, якщо будь-який дочірній workflow виконувався на іншому SHA. -`release_profile` керує широтою реальних перевірок і провайдерів, що передається до release-перевірок. Ручні release-workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку консультативну матрицю провайдерів і медіа. +`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні workflows випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка консультативна матриця provider/media. -- `minimum` зберігає найшвидші критичні для release смуги OpenAI/core. -- `stable` додає стабільний набір провайдерів/backend. -- `full` запускає широку консультативну матрицю провайдерів і медіа. +- `minimum` залишає найшвидші критичні для випуску лінії OpenAI/core. +- `stable` додає стабільний набір provider/backend. +- `full` запускає широку консультативну матрицю provider/media. -Парасольковий workflow записує ідентифікатори запущених дочірніх run, а фінальна job `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших job для кожного дочірнього run. Якщо дочірній workflow перезапустили і він став зеленим, перезапустіть лише батьківську verifier job, щоб оновити результат парасолькового workflow і підсумок часу виконання. +Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасольки та підсумок часу. -Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього prerelease Plugin, `release-checks` для кожного дочірнього release, або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольковому workflow. Це утримує перезапуск невдалого release-бокса обмеженим після цільового виправлення. +Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного повного дочірнього CI, `plugin-prerelease` лише для дочірнього попереднього випуску Plugin, `release-checks` для кожного дочірнього випуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це утримує повторний запуск невдалої release box обмеженим після сфокусованого виправлення. -`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання у tarball `release-package-under-test`, а потім передає цей артефакт і workflow Docker для release-path реальних/E2E перевірок, і shard package acceptance. Це зберігає байти пакета однаковими між release-боксами й уникає повторного пакування того самого кандидата в кількох дочірніх job. +`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до Docker workflow live/E2E шляху випуску, і до shard приймання пакета. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. -Дублікати run `Full Release Validation` для `ref=main` і `rerun_group=all` -замінюють старіший парасольковий workflow. Батьківський монітор скасовує будь-який дочірній workflow, який -уже запустив, коли батьківський workflow скасовано, тому новіша валідація main -не стоїть за застарілим двогодинним release-check run. Валідація release branch/tag -і цільові rerun groups зберігають `cancel-in-progress: false`. +Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all` заміщують старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який він уже запустив, коли батьківський прогін скасовано, тому новіша валідація main не чекає за застарілим двогодинним прогоном release-check. Валідація release branch/tag і сфокусовані групи повторного запуску зберігають `cancel-in-progress: false`. -## Реальні та E2E-шарди +## Live та E2E-шарди -Дочірній release workflow для реальних/E2E перевірок зберігає широке покриття нативних `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість однієї послідовної job: +Дочірній release live/E2E зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: - `native-live-src-agents` - `native-live-src-gateway-core` -- provider-filtered `native-live-src-gateway-profiles` jobs +- provider-filtered завдання `native-live-src-gateway-profiles` - `native-live-src-gateway-backends` - `native-live-test` - `native-live-extensions-a-k` @@ -226,61 +222,59 @@ workflow збігається з target, і видаляє тимчасову br - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- розділені шарди audio/video для медіа й provider-filtered шарди music +- розділені audio/video media шарди та provider-filtered music шарди -Це зберігає те саме файлове покриття, водночас полегшуючи перезапуск і діагностику повільних збоїв реальних провайдерів. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` лишаються дійсними для ручних одноразових перезапусків. +Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. -Нативні шарди реальних media запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed реальні набори тестів на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker-тестів. +Native live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker tests. -Docker-backed шарди реальних model/backend використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Release workflow для реальних перевірок один раз збирає й публікує цей образ, потім Docker-шарди реальної model, provider-sharded Gateway, CLI backend, ACP bind і Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker-шарди Gateway мають явні script-level обмеження `timeout`, нижчі за timeout workflow job, щоб завислий контейнер або шлях cleanup швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, release run налаштовано неправильно, і він марнуватиме реальний час на дубльовані збірки образів. +Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live release workflow один раз збирає і публікує цей образ, після чого Docker live model, provider-sharded Gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker шарди мають явні script-level обмеження `timeout`, нижчі за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані збірки образів. -## Package Acceptance +## Приймання пакета -Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево джерел, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі проходять після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення. -### Jobs +### Завдання -1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує source, workflow ref, package ref, version, SHA-256 і profile у підсумку кроку GitHub. -2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, перевіряє inventory tarball, готує package-digest Docker-образи за потреби й запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгалужує ці lanes як паралельні цільові Docker jobs з унікальними артефактами. -3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; автономний Telegram dispatch усе ще може встановити опубліковану npm spec. -4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або опційна Telegram lane завершилися з помилкою. +1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, workflow ref, package ref, версію, SHA-256 та профіль у GitHub step summary. +2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, валідує інвентар tarball, готує Docker images package-digest за потреби та запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли профіль вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними артефактами. +3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він виконується, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав пакет; автономний Telegram dispatch усе ще може встановлювати опубліковану npm spec. +4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або необов’язкова Telegram lane завершилися з помилкою. ### Джерела кандидатів -- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну release-версію OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованих prerelease/stable. -- `source=ref` пакує довірену `package_ref` branch, tag або повний commit SHA. Resolver fetch-ить branches/tags OpenClaw, перевіряє, що вибраний commit досяжний з історії branch репозиторію або release tag, встановлює deps у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. -- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` опційний, але його варто надати для зовнішньо поширених артефактів. +- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну release version OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих prerelease/stable. +- `source=ref` пакує довірену гілку, tag або повний commit SHA `package_ref`. Resolver fetches OpenClaw branches/tags, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або release tag, встановлює залежності у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. +- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. +- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його варто надати для зовнішньо поширених артефактів. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає змогу поточному test harness перевіряти старіші довірені source commits без запуску старої workflow-логіки. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який виконує тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає поточному test harness змогу валідувати старіші довірені source commits без запуску старої workflow logic. -### Профілі наборів +### Профілі suite - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update` - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full` — повні Docker release-path chunks з OpenWebUI -- `custom` — точні `docker_lanes`; обов’язковий, коли `suite_profile=custom` +- `full` — повні Docker chunks release-path з OpenWebUI +- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Профіль `package` використовує offline Plugin coverage, щоб валідація опублікованого пакета не залежала від доступності реального ClawHub. Опційна Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm spec збережено для автономних dispatch. +Профіль `package` використовує offline plugin coverage, щоб валідація опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm spec збережено для автономних dispatches. -Для спеціальної політики тестування оновлень і Plugin, включно з локальними командами, -Docker lanes, Package Acceptance inputs, release defaults і failure triage, -див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). +Про спеціальну політику тестування оновлень і Plugin, включно з локальними командами, Docker lanes, inputs Package Acceptance, release defaults і triage збоїв, див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). -Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає докази package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline Plugin, plugin-update і Telegram на тому самому розв’язаному package tarball. Встановіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже випущеного npm package замість artifact, зібраного за SHA. Cross-OS release checks усе ще покривають специфічні для OS onboarding, installer і platform behavior; product validation для package/update має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за run. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди перезапуску failed-lane зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен stable npm release від `2026.4.23` до `latest`; `release-history` лишається доступним для ручного ширшого sampling зі старішим pre-date anchor. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених bootstrap/persona files, configured OpenClaw Plugin installs, tilde log paths і stale legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному cleanup для опублікованих оновлень, а не у звичайній широті Full Release CI. Локальні aggregate runs можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений package може імпортувати browser-control override з raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.4`, тож install і Gateway proof лишаються на тестовій моделі GPT-5, уникаючи GPT-4.x defaults. +Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline plugin, plugin-update і Telegram proof на тому самому розв’язаному package tarball. Установіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже доставленого npm package замість SHA-built artifact. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` валідує одну published package baseline за прогін. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди повторного запуску failed-lane зберігають цю baseline. Установіть `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен stable npm release від `2026.4.23` до `latest`; `release-history` залишається доступним для ручного ширшого sampling зі старішим pre-date anchor. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для Feishu config, preserved bootstrap/persona files, configured OpenClaw plugin installs, tilde log paths і stale legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає в exhaustive published update cleanup, а не у звичайній широті Full Release CI. Локальні aggregate runs можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline із вбудованим рецептом команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений package може імпортувати browser-control override із raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.4`, щоб proof встановлення і Gateway залишався на GPT-5 test model, уникаючи GPT-4.x defaults. -### Вікна legacy-сумісності +### Вікна застарілої сумісності -Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих package. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path: +Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path: - відомі private QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball; -- `doctor-switch` може пропускати підвипадок persistence для `gateway install --wrapper`, коли package не експонує цей flag; -- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з fake git fixture, похідного від tarball, і може логувати відсутній persisted `update.channel`; -- Plugin smokes можуть читати legacy install-record locations або приймати відсутню persistence для marketplace install-record; -- `plugin-update` може дозволяти config metadata migration, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior лишалися незмінними. +- `doctor-switch` може пропустити subcase збереження `gateway install --wrapper`, коли package не exposes цей flag; +- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з fake git fixture, похідної від tarball, і може логувати відсутній persisted `update.channel`; +- plugin smokes можуть читати legacy install-record locations або приймати відсутнє marketplace install-record persistence; +- `plugin-update` може дозволяти config metadata migration, усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. -Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були випущені. Пізніші package мають задовольняти сучасні contracts; ті самі умови призводять до failure, а не warn чи skip. +Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були доставлені. Пізніші packages мають відповідати modern contracts; ті самі умови завершуються помилкою замість warn або skip. ### Приклади @@ -323,151 +317,151 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його артефакти Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних ліній Docker замість повторного запуску повної валідації релізу. +Під час налагодження невдалого запуску перевірки прийнятності пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної валідації релізу. -## Перевірка встановлення +## Димова перевірка встановлення -Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення області через власне завдання `preflight`. Він розділяє покриття перевірки на `run_fast_install_smoke` і `run_full_install_smoke`. +Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`. -- **Швидкий шлях** запускається для pull request, що торкаються поверхонь Docker/пакетів, змін пакета/маніфесту вбудованого plugin, або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють завдання Docker smoke. Зміни лише в джерельному коді вбудованого plugin, редагування лише тестів і редагування лише документації не резервують воркери Docker. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI-перевірку видалення agents зі спільного робочого простору, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого розширення та запускає обмежений Docker-профіль вбудованого plugin із сукупним тайм-аутом команди 240 секунд (кожен Docker-запуск сценарію обмежується окремо). -- **Повний шлях** зберігає встановлення QR-пакета та покриття Docker/update інсталятора для нічних запланованих запусків, ручних dispatch, перевірок релізу через workflow-call і pull request, які справді торкаються поверхонь інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ перевірки кореневого Dockerfile для цільового SHA, а потім запускає встановлення QR-пакета, перевірки кореневого Dockerfile/gateway, перевірки інсталятора/update і швидкий Docker E2E для вбудованого plugin як окремі завдання, щоб робота інсталятора не чекала за перевірками кореневого образу. +- **Швидкий шлях** запускається для pull request, що торкаються Docker/пакетних поверхонь, змін пакета/маніфесту вбудованого plugin або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker-димові завдання. Зміни лише вихідного коду вбудованого plugin, редагування лише тестів і редагування лише документації не резервують Docker-воркерів. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI-димову перевірку видалення agents спільного робочого простору, запускає container gateway-network e2e, перевіряє аргумент збирання вбудованого розширення та запускає обмежений Docker-профіль вбудованого plugin із сукупним тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо). +- **Повний шлях** залишає QR-встановлення пакета та Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call перевірок релізу та pull request, які справді торкаються поверхонь інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-димовий образ кореневого Dockerfile для цільового SHA, потім запускає QR-встановлення пакета, димові перевірки кореневого Dockerfile/Gateway, димові перевірки інсталятора/оновлення та швидкий Docker E2E для вбудованого plugin як окремі завдання, щоб робота інсталятора не чекала за димовими перевірками кореневого образу. -Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, workflow зберігає швидку Docker-перевірку та залишає повну перевірку встановлення для нічної або релізної валідації. +Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow зберігає швидку Docker-димову перевірку й залишає повну димову перевірку встановлення для нічної або релізної валідації. -Повільна перевірка image-provider для глобального встановлення Bun окремо контролюється `run_bun_global_install_smoke`. Вона запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть явно її ввімкнути, але pull request і пуші в `main` цього не роблять. Тести QR і Docker інсталятора зберігають власні Dockerfile, зосереджені на встановленні. +Повільна Bun global install image-provider димова перевірка окремо керується `run_bun_global_install_smoke`. Вона запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть увімкнути її, але pull request і пуші в `main` - ні. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на встановленні. ## Локальний Docker E2E `pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: -- базовий раннер Node/Git для ліній installer/update/plugin-dependency; -- функціональний образ, який встановлює той самий tarball у `/app` для ліній звичайної функціональності. +- базовий runner Node/Git для ліній installer/update/plugin-dependency; +- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній. -Визначення ліній Docker містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а раннер виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`. +Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника - у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`. ### Налаштування -| Змінна | Типово | Призначення | -| ------------------------------------- | ------- | -------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу, чутливого до провайдерів. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження одночасних live-ліній, щоб провайдери не застосовували throttling. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження одночасних ліній встановлення npm. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження одночасних багатосервісних ліній. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникнути шквалу створень у daemon Docker; задайте `0`, щоб її вимкнути. | -| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут на лінію (120 хвилин); вибрані live/tail лінії використовують жорсткіші межі. | -| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план планувальника без запуску ліній. | -| `OPENCLAW_DOCKER_ALL_LANES` | unset | Список точних ліній, розділених комами; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. | +| Змінна | Типово | Призначення | +| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів main-pool для звичайних ліній. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-pool, чутливих до провайдера. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live-ліній, щоб провайдери не застосовували throttling. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних ліній npm install. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service ліній. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникнути штормів створення Docker daemon; встановіть `0`, щоб вимкнути затримку. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план планувальника без запуску ліній. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. | -Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight перевіряють Docker, видаляють застарілі контейнери OpenClaw E2E, виводять статус активних ліній, зберігають таймінги ліній для впорядкування за принципом longest-first і типово припиняють планувати нові pooled лінії після першої помилки. +Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight-перевірки перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування longest-first і за замовчуванням припиняють планування нових pooled ліній після першого збою. -### Перевикористовуваний workflow live/E2E +### Повторно використовуваний live/E2E workflow -Перевикористовуваний workflow live/E2E запитує в `scripts/test-docker-all.mjs --plan-json`, який пакет, тип образу, live-образ, лінія та покриття облікових даних потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на outputs і зведення GitHub. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та пушить bare/functional Docker E2E образи GHCR із тегами digest пакета через кеш Docker layer Blacksmith, коли плану потрібні лінії з установленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи за digest пакета замість повторної збірки. Pull образів Docker повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. +Повторно використовуваний live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує artifact пакета з поточного запуску, або завантажує artifact пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує package-digest-tagged bare/functional GHCR Docker E2E образи через Docker layer cache Blacksmith, коли план потребує ліній із установленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Pull Docker-образів повторюється з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. -### Частини шляху релізу +### Фрагменти релізного шляху -Покриття Release Docker запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожна частина завантажувала лише потрібний тип образу та виконувала кілька ліній через той самий зважений планувальник: +Релізне Docker-покриття запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk підтягував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник: - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h` -Поточні частини Release Docker: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються сукупними псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається сукупним ручним псевдонімом повторного запуску для обох ліній інсталятора провайдера. +Поточні release Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються сукупними псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається сукупним ручним псевдонімом повторного запуску для обох provider installer ліній. -OpenWebUI включається до `plugins-runtime-services`, коли цього вимагає повне покриття release-path, і зберігає окрему частину `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення bundled-channel повторюються один раз у разі тимчасових мережевих збоїв npm. +OpenWebUI включається в `plugins-runtime-services`, коли повне release-path покриття запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення вбудованих каналів повторюють спробу один раз для тимчасових npm мережевих збоїв. -Кожна частина завантажує `.artifacts/docker-tests/` з журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що утримує налагодження невдалої лінії в межах одного цільового Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker lane, цільове завдання локально збирає live-test образ для цього повторного запуску. Згенеровані GitHub-команди повторного запуску для кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску. +Кожен chunk завантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує налагодження невдалих ліній одним цільовим Docker-завданням і готує, завантажує або повторно використовує artifact пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільове завдання збирає live-test образ локально для цього повторного запуску. Згенеровані для кожної лінії команди GitHub повторного запуску включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску. ```bash pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands pnpm test:docker:timings # slow-lane and phase critical-path summaries ``` -Запланований workflow live/E2E щодня запускає повний Docker-набір release-path. +Запланований live/E2E workflow щодня запускає повний release-path Docker suite. -## Передреліз Plugin +## Plugin Prerelease -`Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і окремі ручні CI dispatch не вмикають цей набір. Він балансує тести вбудованих plugin між вісьмома воркерами розширень; ці shard jobs розширень запускають до двох груп конфігурації plugin одночасно з одним воркером Vitest на групу та більшим heap Node, щоб import-heavy пакети plugin не створювали додаткові CI jobs. Релізний шлях Docker prerelease групує цільові Docker lanes невеликими групами, щоб не резервувати десятки раннерів для завдань на одну-три хвилини. +`Plugin Prerelease` - дорожче продуктове/пакетне покриття, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і автономні ручні CI dispatch не запускають цей suite. Він балансує тести вбудованих plugin між вісьмома воркерами розширень; ці extension shard jobs запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети plugin не створювали додаткових CI jobs. Релізний Docker prerelease path групує цільові Docker-лінії малими групами, щоб не резервувати десятки runner для завдань тривалістю від однієї до трьох хвилин. ## QA Lab -QA Lab має виділені CI-лінії поза основним smart-scoped workflow. Agentic parity вкладено в широкі QA та release harnesses, а не в окремий PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має виконуватися разом із широким валідаційним запуском. +QA Lab має виділені CI-лінії поза основним smart-scoped workflow. Agentic parity вкладена в широкі QA та релізні harness, а не є автономним PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким запуском валідації. -- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгалужує mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують lease Convex. +- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгортає mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. -Перевірки релізу запускають live transport lanes Matrix і Telegram з детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model і звичайного запуску provider-plugin. Live transport gateway вимикає пошук пам'яті, бо QA parity окремо покриває поведінку пам'яті; підключення провайдерів покривається окремими наборами live model, native provider і Docker provider. +Перевірки релізу запускають Matrix і Telegram live transport lanes із детермінованим mock provider і mock-qualified моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від live model latency і звичайного запуску provider-plugin. Live transport gateway вимикає memory search, тому що QA parity окремо покриває поведінку пам'яті; підключення provider покривається окремими live model, native provider і Docker provider suites. -Matrix використовує `--profile fast` для запланованих і релізних gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Типове значення CLI і ручний input workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди шардить повне покриття Matrix на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. +Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. Типове значення CLI і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix-покриття на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. -`OpenClaw Release Checks` також запускає критичні для релізу лінії QA Lab перед затвердженням релізу; його gate QA parity запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невелике report job для фінального порівняння parity. +`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у мале report job для фінального порівняння parity. -Для звичайних PR дотримуйтеся доказів scoped CI/check замість того, щоб вважати parity обов'язковим статусом. +Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб трактувати parity як обов'язковий статус. ## CodeQL -Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним оглядом репозиторію. Щоденні, ручні та захисні запуски для pull request, що не є чернетками, сканують код робочих процесів Actions разом із поверхнями JavaScript/TypeScript найвищого ризику, використовуючи високонадійні запити безпеки, відфільтровані до high/critical `security-severity`. +Робочий процес `CodeQL` навмисно є вузьким security-сканером першого проходу, а не повним sweep усього репозиторію. Щоденні, ручні та guard-запуски для нечернеткових pull request сканують код робочих процесів Actions, а також поверхні JavaScript/TypeScript із найвищим ризиком, використовуючи високодостовірні security-запити, відфільтровані до високого/критичного `security-severity`. -Захист pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високонадійну матрицю безпеки, що й запланований робочий процес. Android і macOS CodeQL не входять до стандартних PR-перевірок. +Guard для pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високодостовірну security-матрицю, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків. -### Категорії безпеки +### Security категорії -| Категорія | Поверхня | +| Категорія | Поверхня | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Базовий рівень auth, secrets, sandbox, cron і gateway | -| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основного каналу плюс середовище виконання плагіна каналу, gateway, Plugin SDK, secrets, контрольні точки аудиту | -| `/codeql-security-high/network-ssrf-boundary` | Основні поверхні політики SSRF, розбору IP, мережевого захисту, web-fetch і SSRF у Plugin SDK | -| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агентом | -| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для встановлення плагінів, завантажувача, manifest, registry, встановлення через package-manager, завантаження джерел і контракту пакета Plugin SDK | +| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і базова поверхня gateway | +| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс runtime channel plugin, gateway, Plugin SDK, secrets, audit touchpoints | +| `/codeql-security-high/network-ssrf-boundary` | Поверхні core SSRF, парсингу IP, network guard, web-fetch і SSRF-політик Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, helpers виконання процесів, outbound delivery і agent tool-execution gates | +| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для Plugin install, loader, manifest, registry, package-manager install, source-loading і package contract Plugin SDK | -### Платформоспецифічні шардовані перевірки безпеки +### Платформозалежні security shards -- `CodeQL Android Critical Security` — запланована шардована перевірка безпеки Android. Вручну збирає Android-додаток для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Вивантажує під `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — щотижнева/ручна шардована перевірка безпеки macOS. Вручну збирає macOS-додаток для CodeQL на Blacksmith macOS, відфільтровує результати збирання залежностей із вивантаженого SARIF і вивантажує під `/codeql-critical-security/macos`. Залишається поза щоденними стандартними перевірками, бо збирання macOS домінує за часом виконання навіть коли все чисто. +- `CodeQL Android Critical Security` — запланований Android security shard. Вручну збирає Android app для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує в `/codeql-critical-security/android`. +- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Вручну збирає macOS app для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує в `/codeql-critical-security/macos`. Тримається поза щоденними стандартними запускми, бо macOS build домінує runtime навіть коли чистий. -### Категорії Critical Quality +### Critical Quality категорії -`CodeQL Critical Quality` — відповідна шардована перевірка, не пов’язана з безпекою. Вона виконує лише error-severity, не безпекові запити якості JavaScript/TypeScript над вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Її захист pull request навмисно менший за запланований профіль: PR, що не є чернетками, запускають лише відповідні шарди `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для коду виконання команд/моделей/інструментів агентом і диспетчеризації відповідей, коду схеми/міграції/IO конфігурації, коду auth/secrets/sandbox/security, основного каналу й середовища виконання вбудованого плагіна каналу, протоколу Gateway/server-method, runtime пам’яті/SDK-зв’язки, MCP/process/outbound delivery, runtime провайдера/каталогу моделей, session diagnostics/черг доставки, завантажувача плагінів, Plugin SDK/package-contract або змін runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і робочого процесу якості запускають усі дванадцять PR-шардів якості. +`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality-запити на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: нечернеткові PR запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання agent command/model/tool і reply dispatch, коді config schema/migration/IO, коді auth/secrets/sandbox/security, core channel і bundled channel plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни в CodeQL config і quality workflow запускають усі дванадцять PR quality shards. -Ручний запуск приймає: +Manual dispatch приймає: ``` profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Вузькі профілі — це навчальні/ітераційні гачки для запуску одного шарда якості ізольовано. +Вузькі профілі — це teaching/iteration hooks для запуску одного quality shard ізольовано. -| Категорія | Поверхня | -| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки auth, secrets, sandbox, cron і gateway | -| `/codeql-critical-quality/config-boundary` | Контракти схеми конфігурації, міграції, нормалізації та IO | -| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти серверних методів | -| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та вбудованого плагіна каналу | -| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація auto-reply і черги, а також runtime-контракти контрольної площини ACP | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки | -| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, runtime-фасади пам’яті, псевдоніми пам’яті в Plugin SDK, зв’язка активації runtime пам’яті та команди memory doctor | -| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні diagnostic event/log bundle і контракти session doctor CLI | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування session/thread | -| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, auth і discovery провайдера, реєстрація runtime провайдера, defaults/catalogs провайдера та web/search/fetch/embedding registries | -| `/codeql-critical-quality/ui-control-plane` | Bootstrap Control UI, локальна сталість, потоки керування Gateway і runtime-контракти контрольної площини завдань | -| `/codeql-critical-quality/web-media-runtime-boundary` | Контракти runtime для основних web fetch/search, media IO, media understanding, image-generation і media-generation | -| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, registry, публічної поверхні та entrypoint Plugin SDK | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковане джерело Plugin SDK на стороні пакета та допоміжні засоби контракту пакета плагіна | +| Категорія | Поверхня | +| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Код boundary для Auth, secrets, sandbox, cron і gateway security | +| `/codeql-critical-quality/config-boundary` | Контракти config schema, migration, normalization і IO | +| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми Gateway protocol і контракти server method | +| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації core channel і bundled channel plugin | +| `/codeql-critical-quality/agent-runtime-boundary` | Контракти command execution, model/provider dispatch, auto-reply dispatch і queues, а також ACP control-plane runtime | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP servers і tool bridges, helpers нагляду за процесами та контракти outbound delivery | +| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, memory runtime facades, memory Plugin SDK aliases, memory runtime activation glue і memory doctor commands | +| `/codeql-critical-quality/session-diagnostics-boundary` | Reply queue internals, session delivery queues, helpers outbound session binding/delivery, поверхні diagnostic event/log bundle і контракти session doctor CLI | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK inbound reply dispatch, helpers reply payload/chunking/runtime, channel reply options, delivery queues і helpers session/thread binding | +| `/codeql-critical-quality/provider-runtime-boundary` | Model catalog normalization, provider auth і discovery, provider runtime registration, provider defaults/catalogs і web/search/fetch/embedding registries | +| `/codeql-critical-quality/ui-control-plane` | Control UI bootstrap, local persistence, gateway control flows і контракти task control-plane runtime | +| `/codeql-critical-quality/web-media-runtime-boundary` | Контракти core web fetch/search, media IO, media understanding, image-generation і media-generation runtime | +| `/codeql-critical-quality/plugin-boundary` | Контракти loader, registry, public-surface і entrypoint Plugin SDK | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і helpers plugin package contract | -Якість відокремлена від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих плагінів слід повертати лише як подальшу роботу зі scoped або sharded підходом після того, як вузькі профілі матимуть стабільний runtime і сигнал. +Quality залишається окремо від security, щоб quality-знахідки можна було планувати, вимірювати, вимикати або розширювати без затемнення security-сигналу. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільні runtime і signal. -## Робочі процеси обслуговування +## Maintenance workflows ### Docs Agent -Робочий процес `Docs Agent` — це подієво-керована смуга обслуговування Codex для підтримання наявної документації у відповідності з нещодавно внесеними змінами. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, а ручний запуск може виконати його безпосередньо. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший non-skipped запуск Docs Agent був створений за останню годину. Коли він виконується, він переглядає діапазон комітів від попереднього non-skipped source SHA Docs Agent до поточного `main`, тому один погодинний запуск може покрити всі зміни main, накопичені з часу останнього проходу документації. +Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявних docs узгодженими з нещодавно landed changes. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може запустити його напряму. Workflow-run invocations пропускаються, коли `main` уже зрушив далі або коли інший non-skipped Docs Agent run був створений за останню годину. Коли він запускається, він переглядає commit range від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один hourly run може охопити всі main changes, накопичені з останнього docs pass. ### Test Performance Agent -Робочий процес `Test Performance Agent` — це подієво-керована смуга обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується в цей UTC-день. Ручний запуск обходить цей щоденний шлюз активності. Смуга створює повний згрупований звіт продуктивності Vitest, дозволяє Codex робити лише невеликі, coverage-preserving виправлення продуктивності тестів замість широких рефакторингів, потім повторно запускає full-suite звіт і відхиляє зміни, які зменшують базову кількість успішних тестів. Якщо в базовій лінії є тести з помилками, Codex може виправляти лише очевидні збої, а after-agent full-suite report має пройти перед тим, як щось буде закомічено. Коли `main` просувається до того, як bot push потрапляє в репозиторій, смуга ребейзить перевірений патч, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі патчі пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти таку саму drop-sudo safety posture, як і docs agent. +Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних tests. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже запускався або виконується цього UTC-дня. Manual dispatch обходить цей daily activity gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving test performance fixes замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, що зменшують passing baseline test count. Якщо baseline має failing tests, Codex може виправити лише obvious failures, а after-agent full-suite report має пройти, перш ніж щось буде committed. Коли `main` просувається до того, як bot push landed, lane rebases validated patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберігати таку саму drop-sudo safety posture, як docs agent. -### Дублікати PR після злиття +### Duplicate PRs After Merge -Робочий процес `Duplicate PRs After Merge` — це ручний workflow для мейнтейнерів, призначений для очищення дублікатів після landing. За замовчуванням він виконується як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед внесенням змін у GitHub він перевіряє, що landed PR злитий і що кожен дублікат має або спільну referenced issue, або перетин змінених hunks. +Workflow `Duplicate PRs After Merge` — це manual maintainer workflow для post-land duplicate cleanup. За замовчуванням він dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед мутацією GitHub він перевіряє, що landed PR merged і що кожен duplicate має або спільне referenced issue, або overlapping changed hunks. ```bash gh workflow run duplicate-after-merge.yml \ @@ -476,38 +470,115 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Локальні check gates і маршрутизація змін +## Local check gates і changed routing -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI: +Local changed-lane logic міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий CI platform scope: -- зміни core production запускають core prod і core test typecheck плюс core lint/guards; -- зміни лише core test запускають лише core test typecheck плюс core lint; -- зміни extension production запускають extension prod і extension test typecheck плюс extension lint; -- зміни лише extension test запускають extension test typecheck плюс extension lint; -- зміни публічного Plugin SDK або plugin-contract розширюються до extension typecheck, бо розширення залежать від цих core contracts (Vitest extension sweeps залишаються явною тестовою роботою); -- version bumps лише release metadata запускають targeted version/config/root-dependency checks; -- невідомі зміни root/config fail safe до всіх check lanes. +- core production changes запускають core prod і core test typecheck плюс core lint/guards; +- core test-only changes запускають лише core test typecheck плюс core lint; +- extension production changes запускають extension prod і extension test typecheck плюс extension lint; +- extension test-only changes запускають extension test typecheck плюс extension lint; +- зміни public Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються explicit test work); +- release metadata-only version bumps запускають targeted version/config/root-dependency checks; +- unknown root/config changes fail safe до всіх check lanes. -Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі правки тестів запускають самих себе, правки джерел віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Спільна group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt маршрутизуються через основні reply tests плюс Discord і Slack delivery regressions, щоб зміна спільного default зазнала помилки ще до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy. +Local changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі test edits запускають самі себе, source edits віддають перевагу explicit mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із explicit mappings: зміни group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс Discord і Slack delivery regressions, щоб shared default change впала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна настільки harness-wide, що cheap mapped set не є надійним proxy. -## Валідація Testbox +## Testbox validation -Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжому підготовленому боксу для широкої перевірки. Перш ніж витрачати повільну перевірку на бокс, який було повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині боксу. +Запускайте Testbox із кореня репозиторію та віддавайте перевагу свіжій прогрітій машині для широкого підтвердження. Перш ніж витрачати повільну перевірку на машині, яку повторно використали, термін дії якої минув або яка щойно повідомила про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині цієї машини. -Перевірка справності швидко завершується помилкою, коли зникли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть цей бокс і підготуйте свіжий замість налагодження помилки продуктового тесту. Для PR з навмисними масовими видаленнями задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску перевірки справності. +Перевірка sanity швидко завершується з помилкою, коли зникли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть цю машину й прогрійте нову, замість того щоб налагоджувати збій продуктового тесту. Для PR з навмисним великим видаленням задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску sanity. -`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який лишається на етапі синхронізації понад п’ять хвилин без виводу після синхронізації. Задайте `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних diff. +`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Задайте `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних diff-ів. -Crabbox — другий шлях віддаленого боксу, який належить репозиторію, для Linux-перевірки, коли Blacksmith недоступний або коли бажаніше використати власні хмарні ресурси. Підготуйте бокс, наповніть його через workflow проєкту, а потім запускайте команди через Crabbox CLI: +Crabbox — це обгортка для віддалених машин, що належить репозиторію, для maintainer-підтверджень у Linux. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важлива відповідність CI, або коли підтвердження потребує секретів, Docker, пакетних lane-ів, повторно використовуваних машин чи віддалених логів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback для збоїв Blacksmith, проблем із квотами або явного тестування на власних потужностях. + +Перед першим запуском перевірте обгортку з кореня репозиторію: ```bash -pnpm crabbox:warmup -- --idle-timeout 90m -pnpm crabbox:hydrate -- --id -pnpm crabbox:run -- --id --shell "OPENCLAW_TESTBOX=1 pnpm check:changed" -pnpm crabbox:stop -- +pnpm crabbox:run -- --help | sed -n '1,120p' ``` -`.crabbox.yaml` визначає типові параметри провайдера, синхронізації та наповнення GitHub Actions. Він виключає локальний `.git`, щоб наповнений checkout Actions зберігав власні віддалені Git-метадані замість синхронізації локальних maintainer remotes і сховищ об’єктів, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища, яке пізніші команди `crabbox run --id ` використовують як джерело. +Обгортка репозиторію відхиляє застарілий бінарний файл Crabbox, який не рекламує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення owned-cloud. + +Перевірка змін: + +```bash +pnpm crabbox:run -- --provider blacksmith-testbox \ + --blacksmith-org openclaw \ + --blacksmith-workflow .github/workflows/ci-check-testbox.yml \ + --blacksmith-job check \ + --blacksmith-ref main \ + --idle-timeout 90m \ + --ttl 240m \ + --timing-json \ + --shell -- \ + "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm check:changed" +``` + +Сфокусований повторний запуск тесту: + +```bash +pnpm crabbox:run -- --provider blacksmith-testbox \ + --blacksmith-org openclaw \ + --blacksmith-workflow .github/workflows/ci-check-testbox.yml \ + --blacksmith-job check \ + --blacksmith-ref main \ + --idle-timeout 90m \ + --ttl 240m \ + --timing-json \ + --shell -- \ + "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm test " +``` + +Повний набір: + +```bash +pnpm crabbox:run -- --provider blacksmith-testbox \ + --blacksmith-org openclaw \ + --blacksmith-workflow .github/workflows/ci-check-testbox.yml \ + --blacksmith-job check \ + --blacksmith-ref main \ + --idle-timeout 90m \ + --ttl 240m \ + --timing-json \ + --shell -- \ + "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm test" +``` + +Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або очищення незрозуміле, перегляньте активні машини й зупиніть лише ті, які створили ви: + +```bash +blacksmith testbox list +blacksmith testbox stop --id +``` + +Використовуйте повторне використання лише тоді, коли вам навмисно потрібно кілька команд на тій самій гідратованій машині: + +```bash +pnpm crabbox:run -- --provider blacksmith-testbox --id --no-sync --timing-json --shell -- "pnpm test " +pnpm crabbox:stop -- +``` + +Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте прямий Blacksmith як вузький fallback: + +```bash +blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90 +blacksmith testbox run --id "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm check:changed" +blacksmith testbox stop --id +``` + +Переходьте до власних потужностей Crabbox лише тоді, коли Blacksmith недоступний, обмежений квотами, не має потрібного середовища або власні потужності є явною метою: + +```bash +pnpm crabbox:warmup -- --provider aws --class beast --market on-demand --idle-timeout 90m +pnpm crabbox:hydrate -- --id +pnpm crabbox:run -- --id --timing-json --shell -- "env NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm check:changed" +pnpm crabbox:stop -- +``` + +`.crabbox.yaml` визначає типові значення provider, синхронізації та гідратації GitHub Actions для owned-cloud lane-ів. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість синхронізації локальних maintainer-remotes і сховищ об’єктів, а також виключає локальні runtime/build-артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` відповідає за checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища для owned-cloud команд `crabbox run --id `. ## Пов’язане