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

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-05-04 22:33:04 +00:00
parent 7aa79c8ab0
commit a73d1bee3c
4 changed files with 1088 additions and 1055 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

444
docs/uk/ci.md
View File

@ -2,93 +2,93 @@
read_when:
- Потрібно зрозуміти, чому завдання CI виконалося або не виконалося
- Ви налагоджуєте перевірку GitHub Actions, яка не проходить
- Ви координуєте запуск або повторний запуск валідації релізу
- Ви координуєте запуск або повторний запуск перевірки релізу
- Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub
summary: Граф завдань CI, гейти області дії, парасольки релізів і локальні еквіваленти команд
summary: Граф завдань CI, перевірки області, релізні парасольки та локальні еквіваленти команд
title: Конвеєр CI
x-i18n:
generated_at: "2026-05-04T04:57:53Z"
generated_at: "2026-05-04T22:29:59Z"
model: gpt-5.5
provider: openai
source_hash: 72959d0feaf1339f01c9da263153fd89cc4727da6f928933819931991222714d
source_hash: 88d0f7f6cd61d550ec399e8250f685929637cd28638e77aa5a5558775767cac6
source_path: ci.md
workflow: 16
---
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.
OpenClaw CI запускається під час кожного push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно оминають розумне обмеження scope і розгортають повний граф для release candidates і широкої валідації. Android lanes залишаються opt-in через `include_android`. Release-only покриття plugins живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch.
## Огляд pipeline
| Завдання | Призначення | Коли запускається |
| -------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| `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` | Обов’язковий 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 |
| Завдання | Призначення | Коли запускається |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------- |
| `preflight` | Виявляє docs-only зміни, змінені scopes, змінені extensions і збирає CI manifest | Завжди для non-draft pushes і PRs |
| `security-scm-fast` | Виявлення private keys і аудит workflow через `zizmor` | Завжди для non-draft pushes і PRs |
| `security-dependency-audit` | Production lockfile audit без залежностей на основі npm advisories | Завжди для non-draft pushes і PRs |
| `security-fast` | Обов’язковий aggregate для швидких security jobs | Завжди для non-draft pushes і PRs |
| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist для unused files | Node-релевантні зміни |
| `build-artifacts` | Збірка `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-релевантні зміни |
| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни |
| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-релевантні зміни |
| `checks-node-core-test` | Core Node test shards, за винятком channel, bundled, contract і extension lanes | Node-релевантні зміни |
| `check` | Sharded еквівалент main local 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` | Built-CLI smoke tests і startup-memory smoke | Node-релевантні зміни |
| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни |
| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Ручний CI dispatch для releases |
| `check-docs` | Форматування docs, lint і broken-link checks | Змінено docs |
| `skills-python` | Ruff + pytest для Python-backed skills | Python-skill-релевантні зміни |
| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Windows-релевантні зміни |
| `macos-node` | macOS TypeScript test lane із використанням shared built artifacts | macOS-релевантні зміни |
| `macos-swift` | Swift lint, build і tests для macOS app | macOS-релевантні зміни |
| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-релевантні зміни |
| `test-performance-agent` | Щоденна Codex оптимізація slow-test після trusted activity | Main CI success або manual dispatch |
| `openclaw-performance` | Щоденні/on-demand Kova runtime performance reports із 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` падають швидко, не чекаючи на важчі завдання 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`.
1. `preflight` вирішує, які lanes взагалі існують. Логіка `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 lanes, щоб downstream consumers могли стартувати, щойно shared build буде готовий.
4. Важчі platform і runtime lanes розгортаються після цього: `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 failures, але не стають у чергу після того, як увесь workflow уже витіснено. Автоматичний concurrency key CI має версію (`CI-v7-*`), тож GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують runs, що вже виконуються.
GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє до того самого PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже був superseded. Automatic CI concurrency key версіонований (`CI-v7-*`), тому GitHub-side zombie в старій queue group не може нескінченно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
## Область і маршрутизація
## Scope і routing
Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася.
Логіка scope живе в `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 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.
- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
- **CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий 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-specific 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 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/` уже зібрано.
Найповільніші сімейства 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. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено по чотирьох matrix shards, кожен із яких паралельно запускає вибрані 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-релевантного push.
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, водночас уникаючи duplicate debug APK packaging job на кожному Android-релевантному push.
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 не може розв’язати статично.
Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, із вимкненим pnpm minimum release age для `dlx` install) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
## Пересилання активності ClawSweeper
## Переспрямування активності 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`.
`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає ненадійний pull request code. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatches compact `repository_dispatch` payloads до `openclaw/clawsweeper`.
Workflow має чотири напрями:
Workflow має чотири lanes:
- `clawsweeper_item` для точних issue і pull request review requests;
- `clawsweeper_comment` для явних команд ClawSweeper у issue comments;
- `clawsweeper_commit_review` для commit-level review requests на push до `main`;
- `clawsweeper_comment` для явних команд ClawSweeper в issue comments;
- `clawsweeper_commit_review` для commit-level review requests на `main` pushes;
- `github_activity` для загальної GitHub activity, яку агент ClawSweeper може inspect.
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.
Lane `github_activity` пересилає лише normalized 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 до hook OpenClaw Gateway для агента ClawSweeper.
Загальна активність — це спостереження, а не 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`.
Загальна активність є observation, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли event є несподіваним, 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 як untrusted data на всьому цьому шляху. Це input для summarization і triage, а не інструкції для workflow або agent runtime.
Вважайте GitHub titles, comments, bodies, review text, branch names і commit messages ненадійними даними на всьому цьому path. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime.
## Ручні dispatches
Ручні запуски 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.
Ручні dispatch CI запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane не для Android: Linux Node shards, bundled-Plugin shards, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Окремі ручні dispatch CI запускають лише Android з `include_android=true`; повна release-umbrella вмикає Android, передаючи `include_android=true`. Передвипускні статичні перевірки Plugin, release-only shard `agentic-plugins`, повний пакетний sweep розширень і передвипускні Docker lanes для Plugin виключено з CI. Передвипускний Docker suite запускається лише тоді, коли `Full Release Validation` dispatch окремого workflow `Plugin Prerelease` з увімкненим release-validation gate.
Ручні запуски використовують унікальну групу concurrency, щоб повний набір release-candidate не скасовувався іншим push або PR-запуском на тому самому ref. Необов’язковий input `target_ref` дає змогу довіреному викликачеві запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref.
Ручні запуски використовують унікальну concurrency group, тому повний suite реліз-кандидата не скасовується іншим push або PR run на тому самому ref. Необовʼязковий input `target_ref` дає змогу довіреному виклику запустити цей граф для branch, tag або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref.
```bash
gh workflow run ci.yml --ref release/YYYY.M.D
@ -96,17 +96,17 @@ gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_andro
gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
```
## Ранери
## Runners
| Ранер | Завдання |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `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` |
| Runner | Завдання |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, sharded перевірки контрактів каналів, shards `check`, окрім lint, shards і aggregates `check-additional`, aggregate verifiers тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше |
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші 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-sensitive, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі для 32-vCPU коштував більше, ніж заощаджував) |
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest` |
| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` |
## Локальні еквіваленти
@ -137,7 +137,7 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso
## Продуктивність OpenClaw
`OpenClaw Performance` — це workflow продуктивності продукту/середовища виконання. Він щодня запускається на `main` і може запускатися вручну:
`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він запускається щодня на `main` і може запускатися вручну:
```bash
gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
@ -145,31 +145,31 @@ 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 зазвичай benchmark-ить workflow ref. Установіть `target_ref`, щоб benchmark-ити релізний тег або іншу гілку з поточною реалізацією workflow. Опубліковані шляхи звітів і latest pointers індексуються за протестованим ref, а кожен `index.md` записує протестовані ref/SHA, workflow ref/SHA, Kova ref, profile, режим автентифікації lane, модель, кількість повторів і фільтри сценаріїв.
Ручний dispatch зазвичай benchmark workflow ref. Установіть `target_ref`, щоб benchmark release tag або іншу branch із поточною реалізацією workflow. Опубліковані paths звітів і latest pointers keyed by tested ref, а кожен `index.md` фіксує tested ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters.
Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` на pinned input `kova_ref`, а потім запускає три lanes:
- `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` недоступний.
- `mock-provider`: діагностичні scenarios Kova проти local-build runtime з deterministic fake OpenAI-compatible auth.
- `mock-deep-profile`: CPU/heap/trace profiling для startup, gateway і hotspots agent-turn.
- `live-gpt54`: справжній turn агента OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний.
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 mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для default, hook і startup cases із 50 Plugin; повторювані mock-OpenAI цикли hello `channel-chat-baseline`; і CLI startup commands проти booted gateway. Markdown summary source probe розміщено в `source/index.md` у bundle звіту, поруч із raw JSON.
Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`. Поточний pointer tested-ref записується як `openclaw-performance/<tested-ref>/latest-<lane>.json`.
Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також commits `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts у `openclaw/clawgrit-reports` під `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`. Поточний pointer tested-ref записується як `openclaw-performance/<tested-ref>/latest-<lane>.json`.
## Повна валідація релізу
`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-пакета.
`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає branch, tag або повний commit SHA, dispatch ручний workflow `CI` із цією target, dispatch `Plugin Prerelease` для release-only proof Plugin/package/static/Docker і dispatch `OpenClaw Release Checks` для install smoke, package acceptance, cross-OS package checks, QA Lab parity, Matrix і Telegram lanes. Stable/default runs тримають exhaustive live/E2E і Docker release-path coverage за `run_release_soak=true`; `release_profile=full` примусово вмикає це soak coverage, щоб broad advisory validation залишалася broad. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після publishing передайте `npm_telegram_package_spec`, щоб rerun тієї самої Telegram package lane проти published npm package.
Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
матриці етапів, точних назв завдань workflow, відмінностей profile, artifacts і
Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для
stage matrix, точних назв jobs workflow, відмінностей profile, artifacts і
focused rerun handles.
`OpenClaw Release Publish` — це ручний mutating release workflow. Запускайте його
з `release/YYYY.M.D` або `main` після того, як релізний тег існує, і після того,
як preflight OpenClaw npm успішно завершився. Він перевіряє `pnpm plugins:sync:check`,
запускає `Plugin NPM Release` для всіх publishable plugin packages, запускає
`Plugin ClawHub Release` для того самого release SHA і лише потім запускає
`OpenClaw Release Publish` — це ручний mutating release workflow. Dispatch його
з `release/YYYY.M.D` або `main` після того, як release tag існує, і після того, як
OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`,
dispatch `Plugin NPM Release` для всіх publishable packages Plugin, dispatch
`Plugin ClawHub Release` для того самого release SHA, і лише потім dispatch
`OpenClaw NPM Release` зі збереженим `preflight_run_id`.
```bash
@ -180,41 +180,45 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=beta
```
Для pinned commit proof на гілці, що швидко рухається, використовуйте helper замість
Для proof pinned commit на branch, що швидко змінюється, використовуйте helper замість
`gh workflow run ... --ref main -f ref=<sha>`:
```bash
pnpm ci:full-release --sha <full-sha>
```
GitHub workflow dispatch refs мають бути гілками або тегами, а не raw commit SHAs. Helper
пушить тимчасову гілку `release-ci/<sha>-...` на цільовому SHA,
запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен дочірній
workflow `headSha` відповідає цілі, і видаляє тимчасову гілку після завершення
запуску. Umbrella verifier також падає, якщо будь-який дочірній workflow виконувався на
GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs.
Helper pushes тимчасову branch `release-ci/<sha>-...` на target SHA,
dispatch `Full Release Validation` з цього pinned ref, перевіряє, що кожен child
workflow `headSha` збігається з target, і видаляє тимчасову branch після завершення
run. Umbrella verifier також fails, якщо будь-який child workflow запустився на
іншому SHA.
`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні workflows випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка консультативна матриця provider/media.
`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні робочі процеси випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку консультативну матрицю provider/media. `run_release_soak` керує тим, чи перевірки стабільного/типового випуску запускають вичерпний live/E2E та Docker soak для шляху випуску; `full` примусово вмикає soak.
- `minimum` залишає найшвидші критичні для випуску лінії OpenAI/core.
- `stable` додає стабільний набір provider/backend.
- `full` запускає широку консультативну матрицю provider/media.
Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасольки та підсумок часу.
Парасольковий робочий процес записує ідентифікатори запущених дочірніх виконань, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх виконань і додає таблиці найповільніших завдань для кожного дочірнього виконання. Якщо дочірній робочий процес перезапущено і він стає зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасолькового робочого процесу та підсумок часу.
Для відновлення і `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 обмеженим після сфокусованого виправлення.
Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата випуску, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього передрелізу plugin, `release-checks` для кожного дочірнього випуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` у парасольковому робочому процесі. Це зберігає перезапуск невдалої коробки випуску обмеженим після цільового виправлення.
`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до Docker workflow live/E2E шляху випуску, і до shard приймання пакета. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
`OpenClaw Release Checks` використовує довірене посилання робочого процесу, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт до cross-OS перевірок і Package Acceptance, а також до live/E2E Docker-робочого процесу шляху випуску, коли запускається soak-покриття. Це зберігає байти пакета узгодженими між коробками випуску та уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all` заміщують старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який він уже запустив, коли батьківський прогін скасовано, тому новіша валідація main не чекає за застарілим двогодинним прогоном release-check. Валідація release branch/tag і сфокусовані групи повторного запуску зберігають `cancel-in-progress: false`.
Дублікати виконань `Full Release Validation` для `ref=main` і `rerun_group=all`
замінюють старіший парасольковий робочий процес. Батьківський монітор скасовує будь-який дочірній робочий процес, який
він уже запустив, коли батьківський скасовано, тому новіша перевірка main
не чекає за застарілим двогодинним виконанням release-check. Перевірка гілки/тегу випуску
та цільові групи перезапуску зберігають `cancel-in-progress: false`.
## Live та E2E-шарди
## Live та E2E шарди
Дочірній release live/E2E зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
- `native-live-src-agents`
- `native-live-src-gateway-core`
- provider-filtered завдання `native-live-src-gateway-profiles`
- завдання `native-live-src-gateway-profiles` з фільтрацією за provider
- `native-live-src-gateway-backends`
- `native-live-test`
- `native-live-extensions-a-k`
@ -222,59 +226,61 @@ workflow `headSha` відповідає цілі, і видаляє тимчас
- `native-live-extensions-openai`
- `native-live-extensions-o-z-other`
- `native-live-extensions-xai`
- розділені audio/video media шарди та provider-filtered music шарди
- розділені audio/video шарди media та шарди music з фільтрацією за provider
Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви шардів `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` залишаються чинними для ручних одноразових перезапусків.
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.
Нативні live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному робочим процесом `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють ці бінарні файли перед налаштуванням. Тримайте Docker-backed live набори на звичайних Blacksmith runners — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів.
Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. 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 на дубльовані збірки образів.
Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає та пушить цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker шарди Gateway мають явні обмеження `timeout` на рівні скриптів нижче за тайм-аут завдання робочого процесу, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, виконання випуску налаштоване неправильно і марнуватиме реальний час на дублікати збірок образу.
## Приймання пакета
## Package Acceptance
Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення.
Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після встановлення або оновлення.
### Завдання
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 завершилися з помилкою.
1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, посилання робочого процесу, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub.
2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний робочий процес завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує package-digest Docker-образи і запускає вибрані Docker лінії проти цього пакета замість пакування checkout робочого процесу. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний робочий процес готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; окремий dispatch Telegram усе ще може встановити опубліковану npm-специфікацію.
4. `summary` завершує робочий процес з помилкою, якщо розв’язання пакета, Docker acceptance або необов’язкова лінія Telegram завершилися невдало.
### Джерела кандидатів
- `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` необов’язковий, але його варто надати для зовнішньо поширених артефактів.
- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію випуску OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованого передрелізу/стабільного випуску.
- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або тегу випуску, встановлює залежності у відокремленому 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 logic.
Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код робочого процесу/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старіші довірені коміти вихідного коду без запуску старої логіки робочого процесу.
### Профілі 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 chunks release-path з OpenWebUI
- `full` — повні Docker chunks шляху випуску з OpenWebUI
- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
Профіль `package` використовує offline plugin coverage, щоб валідація опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm spec збережено для автономних dispatches.
Профіль `package` використовує offline plugin покриття, щоб перевірка опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для окремих dispatch.
Про спеціальну політику тестування оновлень і Plugin, включно з локальними командами, Docker lanes, inputs Package Acceptance, release defaults і triage збоїв, див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins).
Для спеціальної політики тестування оновлень і plugin, включно з локальними командами,
Docker лініями, входами Package Acceptance, типовими значеннями випуску та тріажем збоїв,
див. [Тестування оновлень і 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 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.
Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом пакета випуску, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'` і `telegram_mode=mock-openai`. Це тримає перевірку міграції пакета, оновлення, очищення застарілих залежностей plugin, відновлення встановлення налаштованого plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному tarball пакета. Встановіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже доставленого npm-пакета замість артефакту, зібраного з SHA. Cross-OS release checks все ще покривають специфічну для ОС поведінку onboarding, installer і platform; перевірка продукту package/update має починатися з Package Acceptance. Docker лінія `published-upgrade-survivor` перевіряє один опублікований baseline пакета за запуск у блокувальному шляху випуску. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опублікований baseline, за замовчуванням `openclaw@latest`; команди перезапуску невдалих ліній зберігають цей baseline. Full Release Validation з `run_release_soak=true` або `release_profile=full` встановлює `published_upgrade_survivor_baselines=all-since-2026.4.23` і `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити перевірку на всі стабільні npm-випуски від `2026.4.23` до `latest` і issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих OpenClaw plugin, tilde шляхів журналів і застарілих коренів залежностей legacy plugin. Окремий робочий процес `Update Migration` використовує Docker лінію `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованих оновлень, а не у звичайній широті Full Release CI. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну лінію з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, як-от `openclaw@2026.4.15`, або встановити `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована лінія налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після запуску Gateway. Windows packaged і installer fresh лінії також перевіряють, що встановлений пакет може імпортувати browser-control override з сирого абсолютного Windows-шляху. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його встановлено, інакше `openai/gpt-5.4`, тому install і gateway proof залишаються на тестовій моделі GPT-5, уникаючи типових значень GPT-4.x.
### Вікна застарілої сумісності
### Вікна legacy сумісності
Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
Package Acceptance має обмежені вікна legacy сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
- відомі private QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
- `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 залишалися незмінними.
- відомі приватні QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не експонує цей прапорець;
- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній збережений `update.channel`;
- plugin smokes можуть читати legacy розташування install-record або приймати відсутність збереження marketplace install-record;
- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були доставлені. Пізніші packages мають відповідати modern contracts; ті самі умови завершуються помилкою замість warn або skip.
Опублікований пакет `2026.4.26` також може попереджати про локальні stamp-файли build metadata, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску.
### Приклади
@ -317,151 +323,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-ліній замість повторного запуску повної валідації релізу.
Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Віддавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes, а не повторному запуску повної валідації релізу.
## Димова перевірка встановлення
## Інсталяційний smoke-тест
Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
Окремий робочий процес `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
- **Швидкий шлях** запускається для 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 як окремі завдання, щоб робота інсталятора не чекала за димовими перевірками кореневого образу.
- **Швидкий шлях** запускається для pull request, які змінюють поверхні Docker/пакетів, зміни пакетів/маніфестів bundled plugin або поверхні ядра plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled plugin, зміни лише тестів і зміни лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke-тест CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо).
- **Повний шлях** зберігає QR package install і installer Docker/update покриття для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді торкаються поверхонь installer/package/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ root Dockerfile smoke для цільового SHA, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб робота installer не чекала за root image smokes.
Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow зберігає швидку Docker-димову перевірку й залишає повну димову перевірку встановлення для нічної або релізної валідації.
Пуші в `main` (включно з merge-комітами) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, робочий процес залишає швидкий Docker smoke і передає повний install smoke нічному запуску або валідації релізу.
Повільна Bun global install image-provider димова перевірка окремо керується `run_bun_global_install_smoke`. Вона запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть увімкнути її, але pull request і пуші в `main` - ні. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на встановленні.
Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` не роблять цього. QR і installer Docker-тести зберігають власні Dockerfile, орієнтовані на інсталяцію.
## Локальний Docker E2E
`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
- базовий runner Node/Git для ліній installer/update/plugin-dependency;
- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
- чистий Node/Git runner для installer/update/plugin-dependency lanes;
- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних lanes.
Визначення 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`.
Визначення Docker lane розміщені в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
### Налаштування
### Параметри налаштування
| Змінна | Типово | Призначення |
| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
| `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 могли відтворити одну невдалу лінію. |
| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних lanes. |
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-пулу, чутливого до провайдерів. |
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live lanes, щоб провайдери не throttled. |
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних lanes для npm install. |
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service lanes. |
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами lanes, щоб уникнути хвиль create у Docker daemon; задайте `0`, щоб вимкнути затримку. |
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний таймаут на lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші обмеження. |
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план планувальника без запуску lanes. |
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Список точних lanes через кому; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу lane. |
Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight-перевірки перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування longest-first і за замовчуванням припиняють планування нових pooled ліній після першого збою.
Lane, важча за свій ефективний ліміт, все одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням зупиняють планування нових pooled lanes після першої помилки.
### Повторно використовуваний live/E2E workflow
### Багаторазовий live/E2E робочий процес
Повторно використовуваний 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.
Багаторазовий live/E2E робочий процес запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, lane і облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та пушить bare/functional GHCR Docker E2E-образи з тегом package digest через Docker layer cache Blacksmith, коли план потребує lanes із встановленим пакетом; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторювався, а не забирав більшість критичного шляху CI.
### Фрагменти релізного шляху
### Частини release-path
Релізне Docker-покриття запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk підтягував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник:
Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу й виконував кілька lanes через той самий зважений планувальник:
- `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 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 ліній.
Поточні 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` залишаються aggregate plugin/runtime aliases. Lane alias `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes.
OpenWebUI включається в `plugins-runtime-services`, коли повне release-path покриття запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення вбудованих каналів повторюють спробу один раз для тимчасових npm мережевих збоїв.
OpenWebUI включається в `plugins-runtime-services`, коли повне release-path coverage запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюють спробу один раз у разі тимчасових npm network failures.
Кожен 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 підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску.
Кожен chunk завантажує `.artifacts/docker-tests/` з журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями slow-lane і командами повторного запуску для кожної lane. Input робочого процесу `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана lane є live Docker lane, цільове job збирає live-test образ локально для цього повторного запуску. Згенеровані команди повторного запуску GitHub для кожної lane містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала lane могла повторно використати точний пакет і образи з невдалого запуску.
```bash
pnpm test:docker:rerun <run-id> # download Docker artifacts and print combined/per-lane targeted rerun commands
pnpm test:docker:timings <summary> # slow-lane and phase critical-path summaries
```
Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
Запланований live/E2E робочий процес щодня запускає повний release-path Docker suite.
## Plugin Prerelease
## Передреліз Plugin
`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 для завдань тривалістю від однієї до трьох хвилин.
`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий робочий процес, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і автономні ручні CI dispatch не вмикають цей suite. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker lanes у невеликі групи, щоб не резервувати десятки runners для завдань тривалістю від однієї до трьох хвилин.
## QA Lab
QA Lab має виділені CI-лінії поза основним smart-scoped workflow. Agentic parity вкладена в широкі QA та релізні harness, а не є автономним PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким запуском валідації.
QA Lab має виділені CI lanes поза основним smart-scoped workflow. Agentic parity вкладений у широкі QA та release harnesses, а не є окремим PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким validation run.
- 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.
- Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і під час manual dispatch; він розгортає mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
Перевірки релізу запускають 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.
Release checks запускають Matrix і Telegram live transport lanes з deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного startup provider-plugin. Live transport gateway вимикає memory search, бо QA parity окремо покриває поведінку memory; provider connectivity покривається окремими live model, native provider і Docker provider suites.
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`.
Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди шардить повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у мале report job для фінального порівняння parity.
`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невелике report job для фінального parity comparison.
Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб трактувати parity як обов'язковий статус.
Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб розглядати parity як required status.
## CodeQL
Робочий процес `CodeQL` навмисно є вузьким security-сканером першого проходу, а не повним sweep усього репозиторію. Щоденні, ручні та guard-запуски для нечернеткових pull request сканують код робочих процесів Actions, а також поверхні JavaScript/TypeScript із найвищим ризиком, використовуючи високодостовірні security-запити, відфільтровані до високого/критичного `security-severity`.
Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та захисні запуски для non-draft pull request сканують код Actions workflow, а також найризикованіші поверхні JavaScript/TypeScript за допомогою високонадійних запитів безпеки, відфільтрованих до високого/критичного `security-severity`.
Guard для pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високодостовірну security-матрицю, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків.
Захист pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високонадійну матрицю безпеки, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків.
### Security категорії
### Категорії безпеки
| Категорія | Поверхня |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `/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 |
| Категорія | Поверхня |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `/codeql-security-high/core-auth-secrets` | Автентифікація, секрети, sandbox, cron і базовий рівень Gateway |
| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основних каналів плюс runtime плагіна каналу, Gateway, Plugin SDK, секрети, точки дотику аудиту |
| `/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` | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення package-manager, завантаження джерел і контракту пакета Plugin SDK |
### Платформозалежні security shards
### Платформоспецифічні фрагменти безпеки
- `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 навіть коли чистий.
- `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 домінує за runtime навіть коли все чисто.
### Critical Quality категорії
### Категорії критичної якості
`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.
`CodeQL Critical Quality` — відповідний фрагмент не для безпеки. Він виконує лише запити якості JavaScript/TypeScript з error-severity, не пов’язані з безпекою, на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: non-draft 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 конфігурації, коді автентифікації/секретів/sandbox/безпеки, runtime основного каналу й вбудованого Plugin каналу, протоколі Gateway/server-method, runtime пам’яті/SDK-зв’язуванні, MCP/процесах/вихідній доставці, runtime провайдера/каталозі моделей, діагностиці сеансів/чергах доставки, завантажувачі Plugin, Plugin SDK/контракті пакета або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять PR-фрагментів якості.
Manual dispatch приймає:
Ручний 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` | Код 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-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, sandbox, cron і Gateway |
| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та IO-контракти |
| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти серверних методів |
| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та вбудованого Plugin каналу |
| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація й черги автовідповідей, а також runtime-контракти контрольної площини ACP |
| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки |
| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, фасади runtime пам’яті, псевдоніми Plugin SDK для пам’яті, зв’язувальний код активації runtime пам’яті та команди doctor для пам’яті |
| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/log bundle і CLI-контракти session doctor |
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Вхідна диспетчеризація відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування сеансу/потоку |
| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та discovery провайдера, реєстрація runtime провайдера, типові налаштування/каталоги провайдера та реєстри web/search/fetch/embedding |
| `/codeql-critical-quality/ui-control-plane` | Початкове завантаження Control UI, локальна персистентність, контрольні потоки Gateway і runtime-контракти контрольної площини завдань |
| `/codeql-critical-quality/web-media-runtime-boundary` | Основні runtime-контракти web fetch/search, media IO, розуміння медіа, image-generation і media-generation |
| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK |
| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковані package-side джерела Plugin SDK і допоміжні засоби контракту пакета плагіна |
Quality залишається окремо від security, щоб quality-знахідки можна було планувати, вимірювати, вимикати або розширювати без затемнення security-сигналу. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільні runtime і signal.
Якість залишається окремо від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих плагінів слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
## Maintenance workflows
## Workflow для обслуговування
### Docs Agent
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.
Workflow `Docs Agent` — це подієво-керована лінія обслуговування Codex для підтримання наявної документації відповідно до нещодавно змерджених змін. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run виклики пропускаються, коли `main` уже просунувся далі або коли інший non-skipped запуск Docs Agent був створений протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з часу останнього проходу документації.
### Test Performance 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.
Workflow `Test Performance Agent` — це подієво-керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, але він пропускається, якщо інший workflow-run виклик уже виконувався або виконується цього UTC-дня. Manual dispatch обходить цей денний activity gate. Лінія будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving виправлення продуктивності тестів замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують базову кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні збої, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму drop-sudo safety posture, що й docs agent.
### Duplicate PRs After Merge
### Дублікати PR після merge
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.
Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land duplicate cleanup. Типово він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільне referenced issue, або overlapping changed hunks.
```bash
gh workflow run duplicate-after-merge.yml \
@ -470,29 +476,29 @@ gh workflow run duplicate-after-merge.yml \
-f apply=true
```
## Local check gates і changed routing
## Локальні check gates і changed routing
Local changed-lane logic міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий CI platform scope:
Локальна changed-lane логіка міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо архітектурних меж, ніж широкий platform scope CI:
- 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.
- зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards;
- зміни лише core test запускають тільки typecheck core test плюс core lint;
- зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint;
- зміни лише extension test запускають typecheck extension test плюс extension lint;
- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (Vitest extension sweeps залишаються explicit test work);
- metadata-only version bumps релізу запускають цільові перевірки version/config/root-dependency;
- невідомі зміни root/config fail safe до всіх check lanes.
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.
Локальний changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі редагування тестів запускають самі себе, редагування джерел віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy.
## Testbox validation
## Валідація Testbox
Запускайте Testbox із кореня репозиторію та віддавайте перевагу свіжій прогрітій машині для широкого підтвердження. Перш ніж витрачати повільну перевірку на машині, яку повторно використали, термін дії якої минув або яка щойно повідомила про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині цієї машини.
Запускайте Testbox з кореня репозиторію і для широкого підтвердження надавайте перевагу свіжому прогрітому боксу. Перш ніж витрачати повільний гейт на бокс, який було повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині боксу.
Перевірка sanity швидко завершується з помилкою, коли зникли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть цю машину й прогрійте нову, замість того щоб налагоджувати збій продуктового тесту. Для PR з навмисним великим видаленням задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску sanity.
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 — це обгортка для віддалених машин, що належить репозиторію, для maintainer-підтверджень у Linux. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важлива відповідність CI, або коли підтвердження потребує секретів, Docker, пакетних lane-ів, повторно використовуваних машин чи віддалених логів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback для збоїв Blacksmith, проблем із квотами або явного тестування на власних потужностях.
Crabbox — це репозиторна обгортка для віддалених боксів, призначена для maintainer Linux-підтверджень. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важливий паритет із CI або коли підтвердження потребує секретів, Docker, пакетних доріжок, повторно використовуваних боксів чи віддалених журналів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback на випадок збоїв Blacksmith, проблем із квотами або явного тестування власних потужностей.
Перед першим запуском перевірте обгортку з кореня репозиторію:
@ -500,9 +506,9 @@ Crabbox — це обгортка для віддалених машин, що
pnpm crabbox:run -- --help | sed -n '1,120p'
```
Обгортка репозиторію відхиляє застарілий бінарний файл Crabbox, який не рекламує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення owned-cloud.
Репозиторна обгортка відмовляється від застарілого бінарного файлу Crabbox, який не оголошує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення для owned-cloud.
Перевірка змін:
Гейт змін:
```bash
pnpm crabbox:run -- --provider blacksmith-testbox \
@ -517,7 +523,7 @@ pnpm crabbox:run -- --provider blacksmith-testbox \
"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 \
@ -547,21 +553,21 @@ pnpm crabbox:run -- --provider blacksmith-testbox \
"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; якщо запуск перервано або очищення незрозуміле, перегляньте активні машини й зупиніть лише ті, які створили ви:
Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або cleanup незрозумілий, перегляньте активні бокси й зупиніть лише ті бокси, які створили ви:
```bash
blacksmith testbox list
blacksmith testbox stop --id <tbx_id>
```
Використовуйте повторне використання лише тоді, коли вам навмисно потрібно кілька команд на тій самій гідратованій машині:
Використовуйте повторне використання лише тоді, коли вам навмисно потрібні кілька команд на тому самому hydrated-боксі:
```bash
pnpm crabbox:run -- --provider blacksmith-testbox --id <tbx_id> --no-sync --timing-json --shell -- "pnpm test <path-or-filter>"
pnpm crabbox:stop -- <tbx_id>
```
Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте прямий Blacksmith як вузький fallback:
Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте direct Blacksmith як вузький fallback:
```bash
blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90
@ -569,7 +575,7 @@ blacksmith testbox run --id <tbx_id> "env CI=1 NODE_OPTIONS=--max-old-space-size
blacksmith testbox stop --id <tbx_id>
```
Переходьте до власних потужностей Crabbox лише тоді, коли Blacksmith недоступний, обмежений квотами, не має потрібного середовища або власні потужності є явною метою:
Переходьте до власних потужностей Crabbox лише коли Blacksmith недоступний, обмежений квотою, не має потрібного середовища або власні потужності є явною метою:
```bash
pnpm crabbox:warmup -- --provider aws --class beast --market on-demand --idle-timeout 90m
@ -578,7 +584,7 @@ pnpm crabbox:run -- --id <cbx_id-or-slug> --timing-json --shell -- "env NODE_OPT
pnpm crabbox:stop -- <cbx_id-or-slug>
```
`.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 <cbx_id>`.
`.crabbox.yaml` володіє типовими значеннями provider, синхронізації та GitHub Actions hydration для owned-cloud доріжок. Він виключає локальний `.git`, щоб hydrated checkout Actions зберігав власні віддалені Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні артефакти runtime/build, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, fetch `origin/main` і передачею несекретного середовища для owned-cloud команд `crabbox run --id <cbx_id>`.
## Пов’язане

846
docs/uk/help/testing.md
View File

File diff suppressed because it is too large Load Diff

650
docs/uk/reference/RELEASING.md
View File

@ -1,267 +1,275 @@
---
read_when:
- Пошук визначень публічних каналів релізів
- Запуск перевірки релізу або приймального тестування пакета
- Шукаємо визначення публічних каналів випуску
- Запуск перевірки релізу або приймання пакета
- Шукаєте іменування версій і періодичність випусків
summary: Канали релізів, контрольний список оператора, середовища валідації, іменування версій і періодичність
summary: Релізні лінії, контрольний список оператора, середовища валідації, іменування версій і періодичність
title: Політика випусків
x-i18n:
generated_at: "2026-05-04T06:33:42Z"
generated_at: "2026-05-04T22:29:51Z"
model: gpt-5.5
provider: openai
source_hash: ef50d3ef5d1e23b4e2c2b097fc4ca9f6d46bf8acb9aea0c9bca6d14e213b88b6
source_hash: fc9b8f82deb90c57c7777480013a5ee956d1123e0b16134daf90a94bc82952cb
source_path: reference/RELEASING.md
workflow: 16
---
OpenClaw має три публічні канали випусків:
- стабільний: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
- бета: теги попередніх випусків, які публікуються в npm `beta`
- розробка: рухома вершина `main`
- stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
- beta: передрелізні теги, які публікуються в npm `beta`
- dev: рухома вершина `main`
## Іменування версій
- Версія стабільного випуску: `YYYY.M.D`
- Git-тег: `vYYYY.M.D`
- Версія корекційного стабільного випуску: `YYYY.M.D-N`
- Версія стабільного коригувального випуску: `YYYY.M.D-N`
- Git-тег: `vYYYY.M.D-N`
- Версія бета-попереднього випуску: `YYYY.M.D-beta.N`
- Версія бета-передрелізу: `YYYY.M.D-beta.N`
- Git-тег: `vYYYY.M.D-beta.N`
- Не додавайте початковий нуль до місяця або дня
- `latest` означає поточний просунутий стабільний npm-випуск
- Не додавайте нулі на початку місяця або дня
- `latest` означає поточний просунутий стабільний випуск npm
- `beta` означає поточну ціль встановлення бета-версії
- Стабільні та корекційні стабільні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлити їх на `latest` або просунути перевірену бета-збірку пізніше
- Кожен стабільний випуск OpenClaw постачає npm-пакет і застосунок macOS разом;
бета-випуски зазвичай спершу перевіряють і публікують шлях npm/package, а
збирання/підпис/нотаризацію застосунку Mac залишають для стабільного випуску, якщо це явно не запитано
- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену бета-збірку
- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS;
бета-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
збірку/підпис/нотаризацію застосунку mac залишають для стабільного випуску, якщо це явно не запитано
## Каденція випусків
## Частота випусків
- Випуски рухаються спершу через бета-версію
- Стабільний випуск іде лише після перевірки останньої бета-версії
- Мейнтейнери зазвичай відгалужують випуски з гілки `release/YYYY.M.D`, створеної
- Випуски рухаються спочатку через beta
- Stable виходить лише після перевірки останньої beta
- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
розробку в `main`
- Якщо бета-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють
наступний тег `-beta.N` замість видалення чи повторного створення старого бета-тега
- Детальна процедура випуску, погодження, облікові дані та нотатки з відновлення
доступні лише мейнтейнерам
- Якщо beta-тег уже надіслано або опубліковано і потрібне виправлення, супровідники створюють
наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення
призначені лише для супровідників
## Контрольний список оператора випуску
Цей контрольний список є публічною формою потоку випуску. Приватні облікові дані,
Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані,
підписування, нотаризація, відновлення dist-tag і деталі екстреного відкоту залишаються в
ранбуку випуску лише для мейнтейнерів.
release runbook лише для супровідників.
1. Почніть із поточного `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано,
і переконайтеся, що поточний CI `main` достатньо зелений, щоб відгалужуватися від нього.
2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою
`/changelog`, залиште записи орієнтованими на користувача, закомітьте його, надішліть і виконайте rebase/pull
ще раз перед відгалуженням.
і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку.
2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте його, надішліть і виконайте rebase/pull
ще раз перед створенням гілки.
3. Перегляньте записи сумісності випуску в
`src/plugins/compat/registry.ts` і
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її
навмисно збережено.
4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу з випуску
навмисно залишено.
4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском
безпосередньо в `main`.
5. Підніміть версію в кожному потрібному місці для запланованого тега, запустіть
`pnpm plugins:sync`, щоб публіковані пакети Plugin мали спільну версію випуску
й метадані сумісності, а потім виконайте локальну детерміновану попередню перевірку:
5. Збільште версію в усіх обов’язкових місцях для запланованого тега, запустіть
`pnpm plugins:sync`, щоб публіковні пакети Plugin мали спільну версію випуску
та метадані сумісності, потім запустіть локальний детермінований preflight:
`pnpm check:test-types`, `pnpm check:architecture`,
`pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і
`pnpm release:check`.
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
для перевірки лише попередньої перевірки дозволено повний 40-символьний SHA гілки випуску.
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега
повний 40-символьний SHA гілки випуску дозволено для preflight лише з метою перевірки.
Збережіть успішний `preflight_run_id`.
7. Запустіть усі передрелізні тести через `Full Release Validation` для
гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
8. Якщо перевірка не проходить, виправте це в гілці випуску й перезапустіть найменший невдалий
файл, канал, завдання workflow, профіль пакета, провайдера або список дозволених моделей, який
доводить виправлення. Перезапускайте повну парасольку лише тоді, коли змінена поверхня робить
для чотирьох великих тестових блоків випуску: Vitest, Docker, QA Lab і Package.
8. Якщо перевірка завершується невдало, виправте проблему в гілці випуску та повторно запустіть найменший невдалий
файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що
доводить виправлення. Повторно запускайте весь umbrella лише тоді, коли змінена поверхня робить
попередні докази застарілими.
9. Для бета-версії створіть тег `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
9. Для beta позначте тегом `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
спершу публікує всі публіковані пакети Plugin в npm, потім публікує той самий
набір у ClawHub як npm-pack tarballs ClawPack, а потім просуває
підготовлений артефакт попередньої перевірки OpenClaw npm з відповідним dist-tag. Після
публікації запустіть post-publish package
acceptance проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
`openclaw@beta`. Якщо надісланий або опублікований попередній випуск потребує виправлення,
створіть наступний відповідний номер попереднього випуску; не видаляйте й не переписуйте старий
попередній випуск.
10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат у випуск матиме
потрібні докази перевірки. Стабільна публікація npm також проходить через
`OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через
спочатку публікує всі публіковні пакети Plugin в npm, потім публікує той самий
набір у ClawHub як tarball-и ClawPack npm-pack, а потім просуває
підготовлений preflight-артефакт OpenClaw npm з відповідним dist-tag. Після
публікації запустіть приймальну перевірку пакета після публікації
для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
`openclaw@beta`. Якщо надісланий або опублікований передреліз потребує виправлення,
створіть наступний відповідний номер передрелізу; не видаляйте і не перезаписуйте старий
передреліз.
10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має
необхідні докази перевірки. Публікація stable npm також проходить через
`OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через
`preflight_run_id`; готовність стабільного випуску macOS також вимагає
запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний
11. Після публікації запустіть npm-перевірник після публікації, необов’язковий автономний
published-npm Telegram E2E, коли потрібен доказ каналу після публікації,
просування dist-tag за потреби, нотатки GitHub release/prerelease з
повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
## Попередня перевірка випуску
## Preflight випуску
- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
покритим поза швидшим локальним шлюзом `pnpm check`
- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
релізні артефакти `dist/*` і бандл Control UI існували для кроку валідації
пакування
- Запустіть `pnpm plugins:sync` після підняття кореневої версії та перед тегуванням. Він
оновлює версії публікованих пакетів Plugin, метадані сумісності OpenClaw peer/API,
метадані збірки та заготовки журналів змін Plugin відповідно до версії основного
релізу. `pnpm plugins:sync:check` — це немодифікуючий релізний запобіжник;
workflow публікації завершується помилкою до будь-якої зміни реєстру, якщо цей крок
було забуто.
релізні артефакти `dist/*` і бандл Control UI існували для кроку
валідації пакування
- Запустіть `pnpm plugins:sync` після підвищення версії в корені й перед тегуванням. Він
оновлює версії пакетів придатних до публікації plugin, метадані сумісності
OpenClaw peer/API, метадані збірки та заготовки журналів змін plugin, щоб вони відповідали
версії основного релізу. `pnpm plugins:sync:check` — це немодифікувальний релізний запобіжник;
workflow публікації завершується помилкою до будь-якої мутації реєстру, якщо цей крок було
забуто.
- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
тег або повний SHA коміту, запускає ручний `CI` і запускає
`OpenClaw Release Checks` для smoke-перевірки встановлення, приймання пакета, Docker
наборів для релізного шляху, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
ліній. З `release_profile=full` і `rerun_group=all` він також запускає пакетний
Telegram E2E проти артефакту `release-package-under-test` із release checks. Передайте
`npm_telegram_package_spec` після публікації, коли той самий Telegram E2E має також
підтвердити опублікований npm-пакет. Передайте `package_acceptance_package_spec` після
публікації, коли Package Acceptance має виконати свою матрицю пакета/оновлення проти
відвантаженого npm-пакета замість артефакту, зібраного з SHA. Передайте
`evidence_package_spec`, коли приватний звіт доказів має підтвердити, що валідація
відповідає опублікованому npm-пакету без примусового Telegram E2E.
`OpenClaw Release Checks` для install smoke, package acceptance, між-ОС
перевірок пакетів, паритету QA Lab, Matrix і Telegram lanes. Стабільні/типові запуски
тримають вичерпні live/E2E та Docker release-path soak за
`run_release_soak=true`; `release_profile=full` примусово вмикає soak. З
`release_profile=full` і `rerun_group=all` він також запускає package Telegram
E2E проти артефакту `release-package-under-test` із release checks.
Надайте `npm_telegram_package_spec` після публікації, коли той самий
Telegram E2E має також підтвердити опублікований npm-пакет. Надайте
`package_acceptance_package_spec` після публікації, коли Package Acceptance
має виконати свою матрицю package/update проти відвантаженого npm-пакета замість
артефакту, зібраного за SHA. Надайте
`evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
Приклад:
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
- Запустіть ручний workflow `Package Acceptance`, коли потрібен додатковий бічний доказ
- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ
для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
`openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, щоб
запакувати довірену гілку/тег/SHA `package_ref` з поточним harness `workflow_ref`;
`source=url` для HTTPS tarball з обов’язковим SHA-256; або `source=artifact` для
tarball, завантаженого іншим запуском GitHub Actions. Workflow розв’язує кандидата в
`openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`,
щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним
harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
Actions. Workflow визначає кандидата як
`package-under-test`, повторно використовує Docker E2E release scheduler проти цього
tarball і може запускати Telegram QA проти того самого tarball з
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані Docker
лінії містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а
`published_upgrade_survivor_baseline` вибирає опубліковану базову версію.
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли
вибрані Docker lanes включають `published-upgrade-survivor`, артефакт пакета
є кандидатом, а `published_upgrade_survivor_baseline` вибирає
опублікований baseline.
Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
Поширені профілі:
- `smoke`: лінії встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
- `package`: лінії пакета/оновлення/Plugin, нативні для артефакту, без OpenWebUI або live ClawHub
- `product`: профіль пакета плюс MCP-канали, очищення cron/субагентів,
- `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
- `package`: artifact-native lanes package/update/plugin без OpenWebUI або live ClawHub
- `product`: профіль package плюс MCP-канали, очищення cron/subagent,
вебпошук OpenAI і OpenWebUI
- `full`: фрагменти Docker релізного шляху з OpenWebUI
- `full`: фрагменти Docker release-path з OpenWebUI
- `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
для кандидата релізу. Ручні запуски CI обходять scoped-перевірки зміненого та примусово
запускають Linux Node shards, bundled-plugin shards, контракти каналів, сумісність
Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills,
Windows, macOS, Android і лінії Control UI i18n.
- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
покриття для релізного кандидата. Ручні запуски CI обходять
changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
перевірки docs, Python skills, Windows, macOS, Android і Control UI i18n
lanes.
Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє
QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span,
обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse
або іншому зовнішньому collector.
- Запускайте `pnpm release:check` перед кожним тегованим релізом
- Запустіть `OpenClaw Release Publish` для модифікуючої послідовності публікації після
появи тегу. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте тег,
досяжний з main), передайте release tag і успішний OpenClaw npm `preflight_run_id`,
і залишайте стандартну область публікації Plugin `all-publishable`, якщо ви навмисно
не виконуєте сфокусоване виправлення. Workflow серіалізує публікацію Plugin у npm,
публікацію Plugin у ClawHub і публікацію OpenClaw у npm, щоб основний пакет не був
опублікований раніше за свої зовнішні Plugin.
QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
span, обмежені атрибути та редагування вмісту/ідентифікаторів без
потреби в Opik, Langfuse або іншому зовнішньому collector.
- Запустіть `pnpm release:check` перед кожним тегованим релізом
- Запустіть `OpenClaw Release Publish` для мутувальної послідовності публікації після того, як
тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте
тег, досяжний із main), передайте релізний тег і успішний OpenClaw npm
`preflight_run_id`, і залишайте типовий scope публікації plugin
`all-publishable`, якщо ви навмисно не виконуєте сфокусоване виправлення. Workflow
серіалізує npm-публікацію plugin, публікацію plugin у ClawHub і npm-публікацію OpenClaw,
щоб основний пакет не був опублікований раніше за його зовнішні
plugins.
- Release checks тепер виконуються в окремому ручному workflow:
`OpenClaw Release Checks`
- `OpenClaw Release Checks` також запускає lane mock parity QA Lab плюс швидкий live
профіль Matrix і Telegram QA lane перед схваленням релізу. Live lanes використовують
середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex
CI. Запустіть ручний workflow `QA-Lab - All Lanes` з `matrix_profile=all` і
`matrix_shards=true`, коли потрібен повний інвентар Matrix transport, media та E2EE
паралельно.
- Крос-ОС валідація встановлення та оновлення runtime є частиною публічних
- `OpenClaw Release Checks` також запускає mock parity lane QA Lab плюс швидкий
live-профіль Matrix і Telegram QA lane перед схваленням релізу. Live
lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди
облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
transport, media та E2EE паралельно.
- Між-ОС валідація runtime встановлення й оновлення є частиною публічних
`OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
повторно використовуваний workflow
багаторазовий workflow
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
- Це розділення навмисне: реальний шлях npm-релізу має бути коротким,
детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки
залишаються у власній lane, щоб не затримувати й не блокувати публікацію
- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким,
детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у своїй
lane, щоб вони не затримували й не блокували публікацію
- Release checks із секретами слід запускати через `Full Release
Validation` або з workflow ref `main`/release, щоб логіка workflow і
секрети залишалися контрольованими
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
розв’язаний коміт досяжний з гілки OpenClaw або release tag
- validation-only preflight `OpenClaw NPM Release` також приймає поточний
повний 40-символьний SHA коміту workflow-гілки без вимоги pushed tag
- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки метаданих
пакета; реальна публікація все одно потребує реального release tag
- Обидва workflow зберігають реальний шлях публікації та promotion на GitHub-hosted
runners, тоді як немодифікуючий шлях валідації може використовувати більші
resolved commit досяжний із гілки OpenClaw або релізного тегу
- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
- Цей шлях SHA є лише validation-only і не може бути підвищений до реальної публікації
- У режимі SHA workflow синтезує `v<package.json version>` лише для
перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу
- Обидва workflow тримають реальний шлях публікації та promotion на GitHub-hosted
runners, тоді як немутувальний шлях валідації може використовувати більші
Blacksmith Linux runners
- Цей workflow запускає
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
- npm release preflight більше не чекає на окрему lane release checks
з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
- npm release preflight більше не чекає на окрему release checks lane
- Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
(або відповідний beta/correction tag) перед схваленням
(або відповідний тег beta/correction) перед схваленням
- Після npm publish запустіть
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
(або відповідну beta/correction version), щоб перевірити шлях встановлення з
(або відповідну версію beta/correction), щоб перевірити шлях встановлення
опублікованого registry у свіжому тимчасовому prefix
- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`,
щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E
проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram.
Локальні одноразові перевірки maintainer можуть пропустити Convex vars і передати три
env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper виконує Parallels npm update/fresh-target validation, запускає `NPM Telegram Beta E2E`, опитує точний workflow run, завантажує artifact і друкує Telegram report.
- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через
проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram.
Локальні одноразові maintainer-запуски можуть пропустити змінні Convex і передати три
env-облікові дані `OPENCLAW_QA_TELEGRAM_*` напряму.
- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper запускає Parallels-валідацію npm update/fresh-target, запускає `NPM Telegram Beta E2E`, опитує точний workflow run, завантажує артефакт і друкує Telegram-звіт.
- Maintainers можуть запустити ту саму post-publish перевірку з GitHub Actions через
ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
не запускається на кожен merge.
не запускається на кожному merge.
- Автоматизація релізів maintainer тепер використовує preflight-then-promote:
- реальна npm-публікація має пройти успішний npm `preflight_run_id`
- реальна npm-публікація має бути запущена з тієї самої гілки `main` або
- реальний npm publish має пройти успішний npm `preflight_run_id`
- реальний npm publish має бути запущений із тієї самої гілки `main` або
`release/YYYY.M.D`, що й успішний preflight run
- stable npm releases за замовчуванням переходять у `beta`
- stable npm publish може явно цілитися в `latest` через workflow input
- мутація token-based npm dist-tag тепер живе в
- стабільні npm-релізи типово спрямовані на `beta`
- стабільний npm publish може явно спрямовуватися на `latest` через input workflow
- token-based мутація npm dist-tag тепер живе в
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
для безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
public repo зберігає лише OIDC-only publish
- public `macOS Release` призначений лише для валідації; коли tag існує лише в
release branch, але workflow запускається з `main`, встановіть
з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
публічний репозиторій зберігає OIDC-only publish
- публічний `macOS Release` є validation-only; коли тег існує лише в
релізній гілці, але workflow запускається з `main`, задайте
`public_release_branch=release/YYYY.M.D`
- реальний private mac publish має пройти успішні private mac
- реальний приватний mac publish має пройти успішні приватні mac
`preflight_run_id` і `validate_run_id`
- реальні publish paths просувають підготовлені artifacts замість повторної
перебудови
- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
щоб release corrections не могли непомітно залишити старіші глобальні встановлення
на базовому stable payload
- npm release preflight fails closed, якщо tarball не містить і
`dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
- реальні publish paths підвищують підготовлені артефакти замість повторної
їх збірки
- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier
також перевіряє той самий шлях temp-prefix upgrade з `YYYY.M.D` до `YYYY.M.D-N`,
щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
базовому стабільному payload
- npm release preflight завершується закритою помилкою, якщо tarball не містить обох
`dist/control-ui/index.html` і непорожнього payload `dist/control-ui/assets/`,
щоб ми знову не відвантажили порожню browser dashboard
- Post-publish verification також перевіряє наявність published plugin entrypoints і
package metadata у встановленому registry layout. Реліз, який відвантажує відсутні
plugin runtime payloads, провалює postpublish verifier і не може бути promoted до `latest`.
- `pnpm test:install:smoke` також застосовує budget npm pack `unpackedSize` до
candidate update tarball, тож installer e2e ловить випадкове pack bloat
- Post-publish verification також перевіряє, що опубліковані entrypoints plugin і
метадані package присутні в установленому registry layout. Реліз, який
відвантажує відсутні runtime payloads plugin, провалює postpublish verifier і
не може бути підвищений до `latest`.
- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для
candidate update tarball, щоб installer e2e ловив випадкове роздуття пакування
до release publish path
- Якщо релізна робота торкалася CI planning, extension timing manifests або
extension test matrices, згенеруйте повторно й перегляньте planner-owned
`plugin-prerelease-extension-shard` matrix outputs з
`.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes
не описували застарілий CI layout
- Готовність stable macOS release також включає updater surfaces:
- GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
- Якщо релізна робота торкнулася планування CI, manifests timing extension або
матриць тестів extension, перегенеруйте й перегляньте planner-owned
matrix outputs `plugin-prerelease-extension-shard` з
`.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
описували застарілий CI layout
- Готовність стабільного macOS-релізу також включає updater surfaces:
- GitHub release має врешті містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
- `appcast.xml` на `main` має вказувати на новий stable zip після publish
- запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
для цієї release version
- запакований app має зберігати non-debug bundle id, непорожню URL Sparkle feed
і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
для цієї версії релізу
## Релізні тестові бокси
`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з
однієї точки входу. Для доказу pinned commit на швидкозмінній гілці використовуйте
`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
однієї точки входу. Для доказу pinned commit на швидко змінюваній гілці використовуйте
helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на target
SHA:
@ -271,8 +279,8 @@ pnpm ci:full-release --sha <full-sha>
Helper пушить `release-ci/<sha>-...`, запускає `Full Release Validation`
з цієї гілки з `ref=<sha>`, перевіряє, що кожен дочірній workflow `headSha`
відповідає target, а потім видаляє тимчасову гілку. Це запобігає випадковому
підтвердженню новішого дочірнього запуску `main`.
збігається з target, а потім видаляє тимчасову гілку. Це запобігає випадковому
підтвердженню нового дочірнього запуску `main`.
Для валідації release branch або tag запускайте його з довіреного workflow
ref `main` і передавайте release branch або tag як `ref`:
@ -287,49 +295,53 @@ gh workflow run full-release-validation.yml \
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
```
Робочий процес визначає цільовий ref, запускає вручну `CI` з
Робочий процес визначає цільовий ref, запускає manual `CI` з
`target_ref=<release-ref>`, запускає `OpenClaw Release Checks`, готує
батьківський артефакт `release-package-under-test` для перевірок, пов’язаних із
пакетом, і запускає окремий package Telegram E2E, коли `release_profile=full` з
батьківський артефакт `release-package-under-test` для перевірок, орієнтованих на пакет, і
запускає автономний package Telegram E2E, коли `release_profile=full` з
`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
Checks` розгалужується на install smoke, cross-OS release checks, live/E2E Docker
release-path coverage, Package Acceptance з Telegram package QA, QA Lab
parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
підсумок `Full Release Validation`
показує `normal_ci` і `release_checks` як успішні. У режимі full/all дочірній
`npm_telegram` також має бути успішним; поза full/all його пропускають, якщо
не було надано опублікований `npm_telegram_package_spec`. Фінальний підсумок
верифікатора містить таблиці найповільніших завдань для кожного дочірнього
запуску, щоб release manager міг бачити поточний критичний шлях без
завантаження логів.
Див. [Повна валідація релізу](/uk/reference/full-release-validation), щоб отримати
повну матрицю етапів, точні назви завдань workflow, відмінності між профілями
stable і full, артефакти та дескриптори для сфокусованих повторних запусків.
Дочірні workflows запускаються з довіреного ref, який виконує `Full Release
Checks` розгортається на install smoke, cross-OS release checks, live/E2E Docker
покриття release-path, коли soak увімкнено, Package Acceptance з Telegram
package QA, QA Lab parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
зведення `Full Release Validation`
показує `normal_ci` і `release_checks` як успішні. У режимі full/all
дочірній `npm_telegram` також має бути успішним; поза full/all він пропускається,
якщо не було надано опублікований `npm_telegram_package_spec`. Фінальне
зведення verifier містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release
manager міг бачити поточний критичний шлях без завантаження логів.
Див. [Повна release validation](/uk/reference/full-release-validation), щоб отримати
повну матрицю етапів, точні назви workflow job, відмінності між stable і full profile,
артефакти та ручки сфокусованого повторного запуску.
Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
старішу release-гілку або тег. Окремого input для workflow-ref у Full Release Validation
старішу release branch або tag. Окремого workflow-ref input для Full Release Validation
немає; вибирайте довірений harness, вибираючи ref запуску workflow.
Не використовуйте `--ref main -f ref=<sha>` для proof точного коміту на рухомому `main`;
Не використовуйте `--ref main -f ref=<sha>` для exact commit proof на рухомій `main`;
raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте
`pnpm ci:full-release --sha <sha>`, щоб створити pinned тимчасову гілку.
`pnpm ci:full-release --sha <sha>`, щоб створити закріплену тимчасову branch.
Використовуйте `release_profile`, щоб вибрати ширину live/provider:
- `minimum`: найшвидший release-critical OpenAI/core live і Docker path
- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
- `full`: stable плюс broad advisory provider/media coverage
- `stable`: minimum плюс stable provider/backend coverage для release approval
- `full`: stable плюс широке advisory provider/media coverage
`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз
визначити цільовий ref як `release-package-under-test`, і повторно використовує
цей артефакт як у release-path Docker checks, так і в Package Acceptance. Це
тримає всі package-facing boxes на тих самих байтах і уникає повторних збірок
пакета. Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
задано repo/org variable, інакше `openai/gpt-5.4`, бо ця lane
доводить встановлення пакета, onboarding, запуск gateway і один live agent turn,
а не benchmark найповільнішої default model. Ширша live provider
Використовуйте `run_release_soak=true` зі `stable`, коли release-blocking lanes
зелені й потрібен вичерпний live/E2E, Docker release-path і
all-since-2026.4.23 upgrade-survivor sweep перед promotion. `full` передбачає
`run_release_soak=true`.
`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий
ref як `release-package-under-test`, і повторно використовує цей артефакт у cross-OS,
Package Acceptance та release-path Docker checks, коли виконується soak. Це утримує
всі package-facing boxes на тих самих байтах і уникає повторних package builds.
Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
repo/org variable задана, інакше `openai/gpt-5.4`, оскільки ця lane
доводить package install, onboarding, запуск gateway і один live agent turn,
а не бенчмаркує найповільнішу default model. Ширша live provider
matrix залишається місцем для model-specific coverage.
Використовуйте ці варіанти залежно від етапу релізу:
Використовуйте ці варіанти залежно від етапу release:
```bash
# Validate an unpublished release candidate branch.
@ -360,17 +372,17 @@ gh workflow run full-release-validation.yml \
```
Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box
падає, використовуйте невдалий child workflow, job, Docker lane, package profile, model
provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді, коли
виправлення змінило спільну release orchestration або зробило попередні all-box evidence
застарілими. Фінальний verifier umbrella повторно перевіряє записані child workflow run
ids, тому після успішного повторного запуску child workflow повторно запускайте тільки failed
батьківське завдання `Verify full validation`.
завершується помилкою, використовуйте failed child workflow, job, Docker lane, package profile, model
provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді,
коли виправлення змінило shared release orchestration або зробило попередні all-box evidence
застарілими. Фінальний verifier umbrella повторно перевіряє записані ids запусків child workflow,
тому після успішного повторного запуску child workflow повторно запустіть лише failed
`Verify full validation` parent job.
Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` є справжнім
release-candidate run, `ci` запускає тільки normal CI child, `plugin-prerelease`
запускає тільки release-only plugin child, `release-checks` запускає кожен release
box, а вужчі release groups: `install-smoke`, `cross-os`,
Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній
release-candidate run, `ci` запускає лише normal CI child, `plugin-prerelease`
запускає лише release-only Plugin child, `release-checks` запускає кожен release
box, а вужчі release groups — це `install-smoke`, `cross-os`,
`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`.
Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all runs
з `release_profile=full` використовують package artifact із release-checks.
@ -379,20 +391,20 @@ box, а вужчі release groups: `install-smoke`, `cross-os`,
Vitest box — це manual `CI` child workflow. Manual CI навмисно
обходить changed scoping і примусово запускає normal test graph для release
candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
candidate: Linux Node shards, bundled-Plugin shards, channel contracts, Node 22
compatibility, `check`, `check-additional`, build smoke, docs checks, Python
skills, Windows, macOS, Android і Control UI i18n.
Використовуйте цей box, щоб відповісти: "чи source tree пройшло full normal test suite?"
Це не те саме, що release-path product validation. Evidence, які слід зберігати:
Використовуйте цей box, щоб відповісти: "чи пройшло source tree повний normal test suite?"
Це не те саме, що release-path product validation. Evidence, яку потрібно зберегти:
- підсумок `Full Release Validation`, що показує URL запущеного `CI` run
- `CI` run зелений на точному target SHA
- назви failed або slow shards із CI jobs під час розслідування regressions
- зведення `Full Release Validation`, що показує dispatched `CI` run URL
- зелений `CI` run на точному target SHA
- назви failed або slow shards із CI jobs під час дослідження regressions
- Vitest timing artifacts, як-от `.artifacts/vitest-shard-timings.json`, коли
запуск потребує performance analysis
Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але
Запускайте manual CI напряму лише тоді, коли release потребує deterministic normal CI, але
не Docker, QA Lab, live, cross-OS або package boxes:
```bash
@ -402,15 +414,15 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
### Docker
Docker box живе в `OpenClaw Release Checks` через
`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
workflow `install-smoke`. Він валідує release candidate через packaged
`openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode
workflow `install-smoke`. Він перевіряє release candidate через packaged
Docker environments, а не лише source-level tests.
Release Docker coverage включає:
- full install smoke з увімкненим slow Bun global install smoke
- підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR,
root/gateway і installer/Bun smoke jobs, що працюють як окремі install-smoke
root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke
shards
- repository E2E lanes
- release-path Docker chunks: `core`, `package-update-openai`,
@ -420,9 +432,9 @@ Release Docker coverage включає:
`plugins-runtime-install-c`, `plugins-runtime-install-d`,
`plugins-runtime-install-e`, `plugins-runtime-install-f`,
`plugins-runtime-install-g` і `plugins-runtime-install-h`
- OpenWebUI coverage усередині chunk `plugins-runtime-services`, коли це запитано
- розділені bundled plugin install/uninstall lanes
`bundled-plugin-install-uninstall-0` through
- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано
- розділені bundled Plugin install/uninstall lanes
`bundled-plugin-install-uninstall-0` до
`bundled-plugin-install-uninstall-23`
- live/E2E provider suites і Docker live model coverage, коли release checks
включають live suites
@ -430,80 +442,81 @@ Release Docker coverage включає:
Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler завантажує
`.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення
використовуйте `docker_lanes=<lane[,lane]>` на reusable live/E2E workflow замість
використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
повторного запуску всіх release chunks. Згенеровані rerun commands включають попередні
`package_artifact_run_id` і prepared Docker image inputs, коли вони доступні, тому
`package_artifact_run_id` і prepared Docker image inputs, коли доступні, тож
failed lane може повторно використати той самий tarball і GHCR images.
### QA Lab
QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic
behavior і channel-level release gate, окремо від Vitest і Docker
behavior і channel-level release gate, окремий від Vitest і Docker
package mechanics.
Release QA Lab coverage включає:
- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6
baseline за допомогою agentic parity pack
- fast live Matrix QA profile з використанням environment `qa-live-shared`
- mock parity lane, що порівнює candidate lane OpenAI з baseline Opus 4.6
за допомогою agentic parity pack
- fast live Matrix QA profile з використанням середовища `qa-live-shared`
- live Telegram QA lane з використанням Convex CI credential leases
- `pnpm qa:otel:smoke`, коли release telemetry потребує явного local proof
- `pnpm qa:otel:smoke`, коли release telemetry потребує explicit local proof
Використовуйте цей box, щоб відповісти: "чи реліз поводиться коректно в QA scenarios і
Використовуйте цей box, щоб відповісти: "чи поводиться release правильно у QA scenarios і
live channel flows?" Зберігайте artifact URLs для parity, Matrix і Telegram
lanes під час схвалення релізу. Full Matrix coverage залишається доступним як
manual sharded QA-Lab run, а не як default release-critical lane.
lanes під час схвалення release. Full Matrix coverage лишається доступним як
manual sharded QA-Lab run, а не default release-critical lane.
### Пакет
### Package
Package box — це installable-product gate. Він підкріплений
Package box — це installable-product gate. Його підтримують
`Package Acceptance` і resolver
`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
candidate у tarball `package-under-test`, який споживає Docker E2E, валідує
package inventory, записує package version і SHA-256, а також тримає
candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє
package inventory, записує package version і SHA-256 та утримує
workflow harness ref окремо від package source ref.
Підтримувані candidate sources:
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release
version
- `source=ref`: запакувати довірену `package_ref` branch, tag або full commit SHA
- `source=ref`: pack довірену `package_ref` branch, tag або full commit SHA
з вибраним harness `workflow_ref`
- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
`OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`,
prepared release package artifact, `suite_profile=custom`,
підготовленим release package artifact, `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 Acceptance тримає migration, update, stale
plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram
package QA проти того самого resolved tarball. Upgrade matrix охоплює кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте
Package Acceptance з `source=npm` для вже shipped candidate або
`telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale
Plugin dependency cleanup, offline Plugin fixtures, Plugin update і Telegram
package QA проти того самого resolved tarball. Blocking release checks використовують
default latest published package baseline; `run_release_soak=true` або
`release_profile=full` розширює до кожного stable npm-published baseline від
`2026.4.23` до `latest` плюс reported-issue fixtures. Використовуйте
Package Acceptance із `source=npm` для вже shipped candidate або
`source=ref`/`source=artifact` для SHA-backed local npm tarball перед
публікацією. Це GitHub-native
заміна більшості package/update coverage, яка раніше потребувала
publish. Це GitHub-native
заміна для більшої частини package/update coverage, яка раніше потребувала
Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
installer і platform behavior, але package/update product validation має
віддавати перевагу Package Acceptance.
Канонічний checklist для update і plugin validation:
[Testing updates and plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
Канонічний checklist для update і Plugin validation —
[Тестування updates і Plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить
plugin install/update, doctor cleanup або published-package migration change.
Exhaustive published update migration з кожного stable пакета `2026.4.23+` є
окремим manual workflow `Update Migration`, а не частиною Full Release CI.
Plugin install/update, doctor cleanup або published-package migration change.
Вичерпна published update migration з кожного stable package `2026.4.23+` —
це окремий manual workflow `Update Migration`, а не частина Full Release CI.
Legacy package-acceptance leniency навмисно обмежена в часі. Packages through
Legacy package-acceptance leniency навмисно обмежена в часі. Packages до
`2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих
в npm: private QA inventory entries missing from the tarball, missing
`gateway install --wrapper`, missing patch files in the tarball-derived git
fixture, missing persisted `update.channel`, legacy plugin install-record
locations, missing marketplace install-record persistence і config metadata
у npm: private QA inventory entries, відсутні в tarball, відсутній
`gateway install --wrapper`, відсутні patch files у tarball-derived git
fixture, відсутній persisted `update.channel`, legacy Plugin install-record
locations, відсутня marketplace install-record persistence і config metadata
migration під час `plugins update`. Опублікований package `2026.4.26` може попереджати
про local build metadata stamp files, які вже були shipped. Later packages
мають відповідати modern package contracts; ті самі gaps провалюють release
про local build metadata stamp files, які вже були shipped. Пізніші packages
мають задовольняти modern package contracts; ті самі gaps провалюють release
validation.
Використовуйте ширші Package Acceptance profiles, коли release question стосується
@ -521,29 +534,32 @@ gh workflow run package-acceptance.yml \
Поширені package profiles:
- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway і перезавантаження конфігурації
- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типовий варіант для release-check
- `product`: `package` плюс MCP-канали, очищення cron/субагентів, вебпошук OpenAI і OpenWebUI
- `smoke`: швидкі лани встановлення пакета/каналу/агента, мережі Gateway і
перезавантаження конфігурації
- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типовий
варіант для release-check
- `product`: `package` плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI
і OpenWebUI
- `full`: фрагменти Docker release-path з OpenWebUI
- `custom`: точний список `docker_lanes` для цільових повторних запусків
- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
Для підтвердження Telegram для пакета-кандидата увімкніть `telegram_mode=mock-openai` або
Для Telegram-підтвердження кандидата пакета увімкніть `telegram_mode=mock-openai` або
`telegram_mode=live-frontier` у Package Acceptance. Workflow передає
розв’язаний tarball `package-under-test` у лінію Telegram; автономний
розв’язаний tarball `package-under-test` у Telegram-лан; окремий
Telegram workflow і далі приймає опубліковану npm-специфікацію для перевірок після публікації.
## Автоматизація публікації релізу
`OpenClaw Release Publish` — звичайна точка входу для змінювальної публікації. Вона
оркеструє workflow trusted-publisher у порядку, потрібному релізу:
`OpenClaw Release Publish` — звичайна мутувальна точка входу для публікації. Вона
оркеструє workflows trusted-publisher у порядку, потрібному для релізу:
1. Забрати тег релізу й визначити його commit SHA.
2. Перевірити, що тег досяжний з `main` або `release/*`.
1. Взяти release tag і визначити його commit SHA.
2. Перевірити, що tag досяжний із `main` або `release/*`.
3. Запустити `pnpm plugins:sync:check`.
4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і
4. Dispatch `Plugin NPM Release` з `publish_scope=all-publishable` і
`ref=<release-sha>`.
5. Запустити `Plugin ClawHub Release` з тією самою областю дії та SHA.
6. Запустити `OpenClaw NPM Release` з тегом релізу, npm dist-tag і
5. Dispatch `Plugin ClawHub Release` з тим самим scope і SHA.
6. Dispatch `OpenClaw NPM Release` з release tag, npm dist-tag і
збереженим `preflight_run_id`.
Приклад публікації beta:
@ -576,90 +592,94 @@ gh workflow run openclaw-release-publish.yml \
-f npm_dist_tag=latest
```
Використовуйте нижчорівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release`
лише для цільового виправлення або повторної публікації. Для виправлення вибраного Plugin передайте
Використовуйте нижчорівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release`
лише для сфокусованого ремонту або повторної публікації. Для ремонту вибраного Plugin передайте
`plugin_publish_scope=selected` і `plugins=@openclaw/name` до
`OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли
пакет OpenClaw не слід публікувати.
пакет OpenClaw не можна публікувати.
## Вхідні дані workflow NPM
## Вхідні дані NPM workflow
`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:
- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
- `tag`: обов’язковий release tag, наприклад `v2026.4.2`, `v2026.4.2-1` або
`v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
повний 40-символьний commit SHA гілки workflow для preflight лише з валідацією
- `preflight_only`: `true` лише для валідації/збірки/пакування, `false` для
справжнього шляху публікації
- `preflight_run_id`: обов’язковий у справжньому шляху публікації, щоб workflow повторно використав
повний 40-символьний workflow-branch commit SHA для preflight лише з валідацією
- `preflight_only`: `true` лише для валідації/build/package, `false` для
реального шляху публікації
- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
підготовлений tarball з успішного preflight-запуску
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типовий — `beta`
- `npm_dist_tag`: цільовий npm tag для шляху публікації; типово `beta`
`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані:
- `tag`: обов’язковий тег релізу; має вже існувати
- `tag`: обов’язковий release tag; має вже існувати
- `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`;
обов’язковий, коли `publish_openclaw_npm=true`
- `npm_dist_tag`: цільовий npm-тег для пакета OpenClaw
- `plugin_publish_scope`: типовий — `all-publishable`; використовуйте `selected` лише
для цільових робіт із виправлення
- `npm_dist_tag`: цільовий npm tag для пакета OpenClaw
- `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише
для сфокусованого ремонтного завдання
- `plugins`: розділені комами назви пакетів `@openclaw/*`, коли
`plugin_publish_scope=selected`
- `publish_openclaw_npm`: типовий — `true`; задавайте `false` лише коли використовуєте
workflow як оркестратор виправлення лише для Plugin
- `publish_openclaw_npm`: типово `true`; установлюйте `false` лише під час використання
workflow як оркестратора ремонту лише для plugins
`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:
- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки із секретами
вимагають, щоб розв’язаний commit був досяжний з гілки OpenClaw або
тегу релізу.
- `ref`: branch, tag або повний commit SHA для валідації. Перевірки із секретами
вимагають, щоб розв’язаний commit був досяжний з branch OpenClaw або
release tag.
- `run_release_soak`: увімкнути вичерпні live/E2E, Docker release-path і
all-since upgrade-survivor soak на стабільних/типових release checks. Примусово
вмикається через `release_profile=full`.
Правила:
- Стабільні й корекційні теги можуть публікуватися або до `beta`, або до `latest`
- Beta prerelease-теги можуть публікуватися лише до `beta`
- Стабільні та корекційні tags можуть публікуватися або до `beta`, або до `latest`
- Beta prerelease tags можуть публікуватися лише до `beta`
- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли
`preflight_only=true`
- `OpenClaw Release Checks` і `Full Release Validation` завжди виконують лише валідацію
- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
- `OpenClaw Release Checks` і `Full Release Validation` завжди
лише валідаційні
- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
workflow перевіряє ці метадані перед продовженням публікації
## Послідовність стабільного npm-релізу
Коли готуєте стабільний npm-реліз:
Під час підготовки стабільного npm-релізу:
1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
- До існування тегу можна використати поточний повний commit SHA гілки workflow
для пробного preflight-запуску лише з валідацією
- До появи tag можна використати поточний повний workflow-branch commit
SHA для валідаційного пробного запуску preflight workflow
2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
коли навмисно хочете пряму стабільну публікацію
3. Запустіть `Full Release Validation` на гілці релізу, тезі релізу або повному
commit SHA, коли потрібні звичайний CI плюс живий кеш промптів, Docker, QA Lab,
Matrix і покриття Telegram з одного ручного workflow
коли навмисно потрібна пряма стабільна публікація
3. Запустіть `Full Release Validation` на release branch, release tag або повному
commit SHA, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
Matrix і Telegram з одного ручного workflow
4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, запустіть
ручний workflow `CI` на release ref натомість
5. Збережіть успішний `preflight_run_id`
6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag`
і збереженим `preflight_run_id`; він публікує зовнішні Plugin до npm
і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm
і ClawHub перед просуванням npm-пакета OpenClaw
7. Якщо реліз потрапив у `beta`, використайте приватний workflow
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
для просування цієї стабільної версії з `beta` до `latest`
7. Якщо реліз потрапив на `beta`, використайте приватний
workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
щоб просунути цю стабільну версію з `beta` до `latest`
8. Якщо реліз навмисно опубліковано безпосередньо до `latest`, а `beta`
має одразу вказувати на ту саму стабільну збірку, використайте той самий приватний
workflow, щоб спрямувати обидва dist-tag на стабільну версію, або дозвольте його запланованій
самовідновлювальній синхронізації перемістити `beta` пізніше
має негайно вказувати на той самий стабільний build, використайте той самий приватний
workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
self-healing синхронізації пізніше перемістити `beta`
Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона все ще
потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
Мутація dist-tag розміщена в приватному repo з міркувань безпеки, оскільки вона все ще
потребує `NPM_TOKEN`, тоді як публічний repo зберігає публікацію лише через OIDC.
Це робить і шлях прямої публікації, і шлях просування beta-first
задокументованими та видимими для операторів.
задокументованими та видимими для оператора.
Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
CLI (`op`) лише всередині окремої tmux-сесії. Не викликайте `op`
напряму з основної оболонки агента; утримання цього всередині tmux робить запити,
сповіщення й обробку OTP видимими та запобігає повторним host-сповіщенням.
CLI (`op`) лише всередині виділеної tmux session. Не викликайте `op`
напряму з головного agent shell; утримання цього всередині tmux робить prompts,
alerts і обробку OTP спостережуваними та запобігає повторним alerts хоста.
## Публічні посилання
@ -673,7 +693,7 @@ CLI (`op`) лише всередині окремої tmux-сесії. Не ви
- [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
- [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
Maintainers використовують приватну документацію релізів у
Maintainers використовують приватну release-документацію в
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
для фактичного runbook.

203
docs/uk/reference/full-release-validation.md
View File

@ -1,24 +1,24 @@
---
read_when:
- Запуск або повторний запуск повної перевірки релізу
- Порівняння профілів перевірки стабільного та повного релізу
- Налагодження збоїв етапу перевірки релізу
summary: Етапи повної перевірки випуску, дочірні робочі процеси, профілі випуску, дескриптори повторного запуску та докази
- Порівняння стабільного та повного профілів перевірки релізу
- Налагодження збоїв на етапі перевірки випуску
summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази
title: Повна перевірка релізу
x-i18n:
generated_at: "2026-05-03T12:10:38Z"
generated_at: "2026-05-04T22:29:50Z"
model: gpt-5.5
provider: openai
source_hash: 038901ad751c00b35f69d7ec5caf74e577dcf2350d7658037c3ecc9ff5fab6d7
source_hash: d67b7f9d413aa0f367b71f03d5325ff73591ee1ee6c77623712ebd15d295ca8b
source_path: reference/full-release-validation.md
workflow: 16
---
`Full Release Validation` є загальною перевіркою релізу. Це єдина ручна
точка входу для передрелізного підтвердження, але більшість роботи відбувається в дочірніх workflow, щоб
невдалий box можна було перезапустити без перезапуску всього релізу.
`Full Release Validation` — це парасолька релізу. Це єдина ручна
точка входу для дорелізного підтвердження, але більшість роботи відбувається в дочірніх робочих процесах, щоб
збійний блок можна було запустити повторно без перезапуску всього релізу.
Запускайте його з довіреного ref workflow, зазвичай `main`, і передавайте релізну гілку,
Запускайте його з довіреного посилання робочого процесу, зазвичай `main`, і передавайте гілку релізу,
тег або повний SHA коміту як `ref`:
```bash
@ -30,125 +30,130 @@ gh workflow run full-release-validation.yml \
-f release_profile=stable
```
Дочірні workflow використовують довірений ref workflow для harness і вхідний
`ref` для кандидата, що тестується. Це забезпечує доступність нової логіки валідації
під час перевірки старішої релізної гілки або тегу.
Дочірні робочі процеси використовують довірене посилання робочого процесу для обв’язки та вхідний
`ref` для кандидата, що тестується. Це зберігає доступність нової логіки валідації
під час перевірки старішої гілки релізу або тегу.
За замовчуванням `release_profile=stable` запускає блокувальні для релізу напрямки й пропускає
вичерпний live/Docker soak. Передайте `run_release_soak=true`, щоб включити
soak-напрямки у стабільний запуск. `release_profile=full` завжди вмикає soak-напрямки, щоб
широкий дорадчий профіль ніколи не втрачав покриття непомітно.
Package Acceptance зазвичай збирає tarball кандидата з розв’язаного
`ref`, включно із запусками для повного SHA, відправленими через `pnpm ci:full-release`. Після
`ref`, включно із запусками за повним SHA, відправленими через `pnpm ci:full-release`. Після
публікації передайте `package_acceptance_package_spec=openclaw@YYYY.M.D` (або
`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю package/update для
поставленого npm-пакета.
`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю пакетів/оновлень проти
опублікованого npm-пакета.
## Етапи верхнього рівня
| Етап | Подробиці |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Розв’язання цілі | **Завдання:** `Resolve target ref`<br />**Дочірній workflow:** немає<br />**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту та записує вибрані вхідні дані.<br />**Повторний запуск:** перезапустіть загальну перевірку, якщо це не вдається. |
| Vitest і звичайний CI | **Завдання:** `Run normal full CI`<br />**Дочірній workflow:** `CI`<br />**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, shards для bundled plugin, контрактами каналів, сумісністю Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, i18n Control UI та Android через загальну перевірку.<br />**Повторний запуск:** `rerun_group=ci`. |
| Передрелізна перевірка Plugin | **Завдання:** `Run plugin prerelease validation`<br />**Дочірній workflow:** `Plugin Prerelease`<br />**Підтверджує:** релізні статичні перевірки Plugin, agentic-покриття plugin, повні batch shards розширень і передрелізні Docker lanes для plugin.<br />**Повторний запуск:** `rerun_group=plugin-prerelease`. |
| Перевірки релізу | **Завдання:** `Run release/live/Docker/QA validation`<br />**Дочірній workflow:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, крос-OS перевірки package, live/E2E suites, chunks релізного Docker-шляху, Package Acceptance, паритет QA Lab, live Matrix і live Telegram.<br />**Повторний запуск:** `rerun_group=release-checks` або вужчий handle release-checks. |
| Артефакт package | **Завдання:** `Prepare release package artifact`<br />**Дочірній workflow:** немає<br />**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на package, яким не потрібно чекати на `OpenClaw Release Checks`.<br />**Повторний запуск:** перезапустіть загальну перевірку або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`. |
| Package Telegram | **Завдання:** `Run package Telegram E2E`<br />**Дочірній workflow:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження package Telegram, підкріплене батьківським артефактом, для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого package, коли встановлено `npm_telegram_package_spec`.<br />**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. |
| Верифікатор загальної перевірки | **Завдання:** `Verify full validation`<br />**Дочірній workflow:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших завдань із дочірніх workflow.<br />**Повторний запуск:** перезапустіть лише це завдання після успішного перезапуску невдалого дочірнього workflow. |
| Етап | Деталі |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Розв’язання цілі | **Завдання:** `Resolve target ref`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** розв’язує гілку релізу, тег або повний SHA коміту й записує вибрані вхідні дані.<br />**Повторний запуск:** повторно запустіть парасольку, якщо це завершиться збоєм. |
| Vitest і звичайний CI | **Завдання:** `Run normal full CI`<br />**Дочірній робочий процес:** `CI`<br />**Підтверджує:** ручний повний граф CI проти цільового ref, включно з напрямками Linux Node, шардами bundled Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.<br />**Повторний запуск:** `rerun_group=ci`. |
| Дореліз Plugin | **Завдання:** `Run plugin prerelease validation`<br />**Дочірній робочий процес:** `Plugin Prerelease`<br />**Підтверджує:** лише релізні статичні перевірки Plugin, agentic-покриття Plugin, повні шарди batch розширень і дорелізні Docker-напрямки Plugin.<br />**Повторний запуск:** `rerun_group=plugin-prerelease`. |
| Перевірки релізу | **Завдання:** `Run release/live/Docker/QA validation`<br />**Дочірній робочий процес:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, cross-OS перевірки пакета, Package Acceptance, паритет QA Lab, live Matrix і live Telegram. З `run_release_soak=true` або `release_profile=full` також запускає вичерпні live/E2E набори та Docker-фрагменти шляху релізу.<br />**Повторний запуск:** `rerun_group=release-checks` або вужчий дескриптор release-checks. |
| Артефакт пакета | **Завдання:** `Prepare release package artifact`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на пакет, яким не потрібно чекати на `OpenClaw Release Checks`.<br />**Повторний запуск:** повторно запустіть парасольку або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`. |
| Package Telegram | **Завдання:** `Run package Telegram E2E`<br />**Дочірній робочий процес:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження пакета Telegram на основі батьківського артефакту для `rerun_group=all` з `release_profile=full` або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.<br />**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. |
| Верифікатор парасольки | **Завдання:** `Verify full validation`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших завдань із дочірніх робочих процесів.<br />**Повторний запуск:** повторно запустіть лише це завдання після повторного запуску невдалого дочірнього процесу до зеленого стану. |
Для `ref=main` і `rerun_group=all` новіша загальна перевірка замінює старішу.
Коли батьківський workflow скасовано, його monitor скасовує будь-який дочірній workflow, який він уже
відправив. Запуски перевірки релізних гілок і тегів за замовчуванням не скасовують один одного.
Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу.
Коли батьківський процес скасовується, його монітор скасовує будь-який дочірній робочий процес, який він уже
відправив. Запуски валідації гілок релізу й тегів за замовчуванням не скасовують один одного.
## Етапи перевірок релізу
`OpenClaw Release Checks` є найбільшим дочірнім workflow. Він розв’язує ціль
один раз і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам,
орієнтованим на package або Docker.
`OpenClaw Release Checks` — найбільший дочірній робочий процес. Він один раз розв’язує ціль
і готує спільний артефакт `release-package-under-test`, коли це потрібно етапам,
орієнтованим на пакет або Docker.
| Етап | Подробиці |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Релізна ціль | **Завдання:** `Resolve target ref`<br />**Підтримувальний workflow:** немає<br />**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та сфокусований фільтр live suite.<br />**Повторний запуск:** `rerun_group=release-checks`. |
| Артефакт package | **Завдання:** `Prepare release package artifact`<br />**Підтримувальний workflow:** немає<br />**Тести:** пакує або розв’язує один tarball кандидата й завантажує `release-package-under-test` для подальших перевірок, орієнтованих на package.<br />**Повторний запуск:** відповідна група package, cross-OS або live/E2E. |
| Install smoke | **Завдання:** `Run install smoke`<br />**Підтримувальний workflow:** `Install Smoke`<br />**Тести:** повний шлях установлення з повторним використанням root Dockerfile smoke image, встановлення QR package, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий bundled-plugin install/uninstall E2E.<br />**Повторний запуск:** `rerun_group=install-smoke`. |
| Cross-OS | **Завдання:** `cross_os_release_checks`<br />**Підтримувальний workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тести:** fresh і upgrade lanes у Linux, Windows і macOS для вибраного provider і mode, з використанням tarball кандидата та baseline package.<br />**Повторний запуск:** `rerun_group=cross-os`. |
| Repo та live E2E | **Завдання:** `Run repo/live E2E validation`<br />**Підтримувальний workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані за `release_profile`.<br />**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. |
| Docker release path | **Завдання:** `Run Docker release-path validation`<br />**Підтримувальний workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** chunks релізного Docker-шляху для спільного артефакта package.<br />**Повторний запуск:** `rerun_group=live-e2e`. |
| Package Acceptance | **Завдання:** `Run package acceptance`<br />**Підтримувальний workflow:** `Package Acceptance`<br />**Тести:** offline fixtures package plugin, оновлення plugin, приймання package mock-OpenAI Telegram і перевірки збереження published-upgrade з кожного stable npm release на або після `2026.4.23` для того самого tarball.<br />**Повторний запуск:** `rerun_group=package`. |
| QA parity | **Завдання:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Підтримувальний workflow:** прямі завдання<br />**Тести:** candidate і baseline agentic parity packs, потім parity report.<br />**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`. |
| QA live Matrix | **Завдання:** `Run QA Lab live Matrix lane`<br />**Підтримувальний workflow:** пряме завдання<br />**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. |
| QA live Telegram | **Завдання:** `Run QA Lab live Telegram lane`<br />**Підтримувальний workflow:** пряме завдання<br />**Тести:** live Telegram QA з leases облікових даних Convex CI.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. |
| Верифікатор релізу | **Завдання:** `Verify release checks`<br />**Підтримувальний workflow:** немає<br />**Тести:** обов’язкові завдання release-check для вибраної групи повторного запуску.<br />**Повторний запуск:** перезапустіть після проходження сфокусованих дочірніх завдань. |
| Етап | Подробиці |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Ціль релізу | **Завдання:** `Resolve target ref`<br />**Базовий workflow:** немає<br />**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та сфокусований фільтр live-набору.<br />**Повторний запуск:** `rerun_group=release-checks`. |
| Артефакт пакета | **Завдання:** `Prepare release package artifact`<br />**Базовий workflow:** немає<br />**Тести:** пакує або визначає один кандидатний tarball і завантажує `release-package-under-test` для подальших перевірок, орієнтованих на пакет.<br />**Повторний запуск:** відповідна група пакета, cross-OS або live/E2E. |
| Install smoke | **Завдання:** `Run install smoke`<br />**Базовий workflow:** `Install Smoke`<br />**Тести:** повний шлях встановлення з повторним використанням smoke-образу кореневого Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий E2E встановлення/видалення bundled-plugin.<br />**Повторний запуск:** `rerun_group=install-smoke`. |
| Cross-OS | **Завдання:** `cross_os_release_checks`<br />**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тести:** свіжі та upgrade-напрями на Linux, Windows і macOS для вибраного провайдера та режиму з використанням кандидатного tarball і baseline-пакета.<br />**Повторний запуск:** `rerun_group=cross-os`. |
| Repo і live E2E | **Завдання:** `Run repo/live E2E validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і Plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані через `release_profile`.<br />**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. |
| Шлях Docker-релізу | **Завдання:** `Run Docker release-path validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** Docker chunks для release-path на спільному артефакті пакета.<br />**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`. |
| Package Acceptance | **Завдання:** `Run package acceptance`<br />**Базовий workflow:** `Package Acceptance`<br />**Тести:** offline fixtures пакетів Plugin, оновлення Plugin, приймання mock-OpenAI Telegram-пакета та перевірки survivor для published-upgrade на тому самому tarball. Блокувальні release-перевірки використовують стандартний останній опублікований baseline; soak-перевірки розширюються до кожного стабільного npm-релізу від `2026.4.23` включно плюс fixtures для повідомлених проблем.<br />**Повторний запуск:** `rerun_group=package`. |
| QA parity | **Завдання:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Базовий workflow:** прямі jobs<br />**Тести:** кандидатні та baseline agentic parity packs, потім parity report.<br />**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`. |
| QA live Matrix | **Завдання:** `Run QA Lab live Matrix lane`<br />**Базовий workflow:** пряме job<br />**Тести:** швидкий live Matrix QA-профіль у середовищі `qa-live-shared`.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. |
| QA live Telegram | **Завдання:** `Run QA Lab live Telegram lane`<br />**Базовий workflow:** пряме job<br />**Тести:** live Telegram QA з орендами облікових даних Convex CI.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. |
| Верифікатор релізу | **Завдання:** `Verify release checks`<br />**Базовий workflow:** немає<br />**Тести:** обов’язкові release-check jobs для вибраної групи повторного запуску.<br />**Повторний запуск:** повторно запустіть після успішного проходження сфокусованих дочірніх jobs. |
## Chunks Docker release-path
## Фрагменти Docker release-path
Етап Docker release-path запускає ці chunks, коли `live_suite_filter` є
порожнім:
Етап Docker release-path запускає ці фрагменти, коли `live_suite_filter`
порожній:
| Chunk | Покриття |
| --------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `core` | Core Docker release-path smoke lanes. |
| `package-update-openai` | Поведінка встановлення й оновлення package OpenAI. |
| `package-update-anthropic` | Поведінка встановлення й оновлення package Anthropic. |
| `package-update-core` | Нейтральна щодо provider поведінка package і update. |
| `plugins-runtime-plugins` | Runtime lanes Plugin, що перевіряють поведінку plugin. |
| `plugins-runtime-services` | Runtime lanes Plugin, підкріплені сервісом; включає OpenWebUI, коли запитано. |
| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch встановлення/runtime Plugin, розділені для паралельної валідації релізу. |
| Фрагмент | Покриття |
| -------------------------------------------------------------- | ------------------------------------------------------------------------ |
| `core` | Core Docker release-path smoke-напрями. |
| `package-update-openai` | Поведінка встановлення та оновлення пакета OpenAI. |
| `package-update-anthropic` | Поведінка встановлення та оновлення пакета Anthropic. |
| `package-update-core` | Нейтральна щодо провайдера поведінка пакета й оновлення. |
| `plugins-runtime-plugins` | Напрями runtime Plugin, які перевіряють поведінку Plugin. |
| `plugins-runtime-services` | Напрями runtime Plugin з підтримкою сервісів; включає OpenWebUI за запитом. |
| `plugins-runtime-install-a` до `plugins-runtime-install-h` | Пакети встановлення/runtime Plugin, розділені для паралельної валідації релізу. |
Використовуйте цільовий `docker_lanes=<lane[,lane]>` у повторно використовуваному live/E2E workflow, коли
завершився з помилкою лише один Docker-лан. Артефакти релізу містять команди
повторного запуску для кожного лану з вхідними параметрами повторного використання
артефакта пакета й образу, коли вони доступні.
Використовуйте цільові `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow, коли
збій стався лише в одному Docker-напрямі. Артефакти релізу містять команди
повторного запуску для кожного напряму з artifact пакета та вхідними даними повторного використання образу, коли вони доступні.
## Профілі релізу
`release_profile` переважно керує широтою live/провайдерів у перевірках релізу.
Він не прибирає звичайний повний CI, Plugin Prerelease, install smoke, package
acceptance, QA Lab або фрагменти Docker release-path. `full` також змушує
зонтичний запуск виконувати package Telegram E2E з батьківським артефактом пакета релізу, коли
`rerun_group=all`, тож повний кандидат перед публікацією не пропускає тихо цей
Telegram package-лан.
`release_profile` переважно керує шириною live/provider усередині release checks.
Він не прибирає звичайний full CI, Plugin Prerelease, install smoke, package
acceptance або QA Lab. Для `stable` вичерпні repo/live E2E і Docker
release-path chunks є soak-покриттям і запускаються, коли `run_release_soak=true`.
`full` примусово вмикає soak-покриття, а також змушує umbrella-запуск виконувати package Telegram
E2E проти артефакта пакета батьківського релізу, коли `rerun_group=all`, щоб повний
pre-publish кандидат не пропускав непомітно цей напрям Telegram package.
| Профіль | Призначення | Включене покриття live/провайдерів |
| -------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `minimum` | Найшвидший критичний smoke для релізу. | OpenAI/core live path, Docker live models для OpenAI, нативне ядро Gateway, нативний профіль OpenAI Gateway, нативний OpenAI Plugin і Docker live gateway OpenAI. |
| `stable` | Типовий профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go. |
| `full` | Широкий консультативний sweep. | `stable` плюс консультативні провайдери, live-шарди Plugin і live-шарди медіа. |
| Профіль | Призначене використання | Включене live/provider-покриття |
| -------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live path, Docker live models для OpenAI, native gateway core, native OpenAI gateway profile, native OpenAI plugin і Docker live gateway OpenAI. |
| `stable` | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і OpenCode Go smoke shard. |
| `full` | Широкий advisory sweep. | `stable` плюс advisory providers, plugin live shards і media live shards. |
## Доповнення лише для full
## Додатки лише для full
Ці набори пропускаються в `stable` і включаються в `full`:
| Область | Покриття лише для full |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Docker live models | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. |
| Docker live gateway | Консультативні провайдери, розділені на шарди DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai. |
| Нативні профілі провайдерів Gateway | Повні шарди Anthropic Opus і Sonnet/Haiku, Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. |
| Нативні live-шарди Plugin | Plugins A-K, L-N, O-Z other, Moonshot і xAI. |
| Нативні live-шарди медіа | Audio, Google music, MiniMax music і video groups A-D. |
| Docker live gateway | Advisory providers, розділені на shards DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai. |
| Native gateway provider profiles | Full Anthropic Opus і Sonnet/Haiku shards, Fireworks, DeepSeek, full OpenCode Go model shards, OpenRouter, xAI і Z.ai. |
| Native plugin live shards | Plugins A-K, L-N, O-Z other, Moonshot і xAI. |
| Native media live shards | Audio, Google music, MiniMax music і video groups A-D. |
`stable` включає `native-live-src-gateway-profiles-anthropic-smoke` і
`native-live-src-gateway-profiles-opencode-go-smoke`; `full` натомість використовує ширші
шарди моделей Anthropic і OpenCode Go. Сфокусовані повторні запуски все ще можуть використовувати
агреговані handle `native-live-src-gateway-profiles-anthropic` або
Anthropic і OpenCode Go model shards. Сфокусовані повторні запуски все ще можуть використовувати
агреговані handles `native-live-src-gateway-profiles-anthropic` або
`native-live-src-gateway-profiles-opencode-go`.
## Сфокусовані повторні запуски
Використовуйте `rerun_group`, щоб не повторювати не пов’язані з цим релізні бокси:
Використовуйте `rerun_group`, щоб не повторювати непов’язані release boxes:
| Handle | Обсяг |
| Ідентифікатор | Область |
| ------------------- | --------------------------------------------------------------------- |
| `all` | Усі етапи Full Release Validation. |
| `all` | Усі етапи повної валідації релізу. |
| `ci` | Лише дочірній ручний повний CI. |
| `plugin-prerelease` | Лише дочірній Plugin Prerelease. |
| `release-checks` | Усі етапи OpenClaw Release Checks. |
| `plugin-prerelease` | Лише дочірній попередній реліз Plugin. |
| `release-checks` | Усі етапи перевірок релізу OpenClaw. |
| `install-smoke` | Install Smoke через перевірки релізу. |
| `cross-os` | Перевірки релізу Cross-OS. |
| `live-e2e` | Repo/live E2E і перевірка Docker release-path. |
| `package` | Package Acceptance. |
| `qa` | QA parity плюс QA live-лани. |
| `qa-parity` | Лише QA parity-лани та звіт. |
| `qa-live` | Лише QA live Matrix і Telegram. |
| `npm-telegram` | Published-package Telegram E2E; потребує `npm_telegram_package_spec`. |
| `cross-os` | Перевірки релізу для різних ОС. |
| `live-e2e` | Валідація E2E repo/live і шляху релізу Docker. |
| `package` | Приймання пакета. |
| `qa` | Паритет QA плюс live-напрями QA. |
| `qa-parity` | Лише напрями паритету QA і звіт. |
| `qa-live` | Лише live Matrix і Telegram для QA. |
| `npm-telegram` | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. |
Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли збій стався в одному live-наборі.
Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли один live-набір не пройшов.
Дійсні ідентифікатори фільтрів визначені в повторно використовуваному live/E2E workflow, зокрема
`docker-live-models`, `live-gateway-docker`,
`live-gateway-anthropic-docker`, `live-gateway-google-docker`,
@ -156,22 +161,22 @@ Telegram package-лан.
`live-cli-backend-docker`, `live-acp-bind-docker` і
`live-codex-harness-docker`.
Handle `live-gateway-advisory-docker` є агрегованим handle повторного запуску для його
трьох шардів провайдерів, тому він усе одно розгортається на всі завдання advisory Docker gateway.
Ідентифікатор `live-gateway-advisory-docker` є агрегованим ідентифікатором повторного запуску для своїх
трьох сегментів провайдерів, тому він усе одно розгортається до всіх advisory-завдань Docker gateway.
## Докази, які потрібно зберегти
## Докази, які слід зберегти
Зберігайте зведення `Full Release Validation` як індекс рівня релізу. Воно посилається на
ідентифікатори дочірніх запусків і містить таблиці найповільніших завдань. Для збоїв спершу
перегляньте дочірній workflow, а потім повторно запустіть найменший відповідний handle вище.
ідентифікатори дочірніх запусків і містить таблиці найповільніших завдань. У разі збоїв спершу перевірте дочірній
workflow, потім повторно запустіть найменший відповідний ідентифікатор вище.
Корисні артефакти:
- `release-package-under-test` з батьківського Full Release Validation і `OpenClaw Release Checks`
- Артефакти Docker release-path у `.artifacts/docker-tests/`
- `package-under-test` з Package Acceptance і артефакти Docker acceptance
- Артефакти перевірок релізу Cross-OS для кожної ОС і набору
- Артефакти QA parity, Matrix і Telegram
- Артефакти шляху релізу Docker у `.artifacts/docker-tests/`
- Package Acceptance `package-under-test` і артефакти приймання Docker
- Артефакти перевірок релізу для різних ОС для кожної ОС і набору
- Артефакти паритету QA, Matrix і Telegram
## Файли workflow