chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
2fce993a48
commit
1adbf0cd2f
364
docs/uk/ci.md
364
docs/uk/ci.md
@ -1,75 +1,75 @@
|
||||
---
|
||||
read_when:
|
||||
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
|
||||
- Потрібно зрозуміти, чому завдання CI було або не було запущено
|
||||
- Ви налагоджуєте перевірку GitHub Actions, яка не проходить
|
||||
- Ви координуєте запуск або повторний запуск валідації релізу
|
||||
summary: Граф завдань CI, шлюзи області дії, релізні парасолі та локальні еквіваленти команд
|
||||
summary: Граф завдань CI, гейти за областю дії, парасолькові релізні перевірки та локальні еквіваленти команд
|
||||
title: CI-конвеєр
|
||||
x-i18n:
|
||||
generated_at: "2026-05-01T23:10:06Z"
|
||||
generated_at: "2026-05-01T23:38:38Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 4475dd906e2a7b7675a01ec72e7782f75ccbb4769bd0333c3f56acea9f343893
|
||||
source_hash: e3aeba9260d2eb6b65f1775d457f3dd7c5470ba628e9234409e3a8483a453b48
|
||||
source_path: ci.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw CI запускається для кожного push у `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний граф для реліз-кандидатів і широкої валідації. Android-лінії залишаються opt-in через `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` навмисно обходять розумне обмеження області та розгортають повний граф для release candidates і широкої валідації. Android lanes залишаються opt-in через `include_android`. Покриття Plugin лише для релізу розміщене в окремому workflow [`Plugin передвипуск`](#plugin-prerelease) і запускається лише з [`Повна валідація релізу`](#full-release-validation) або явного ручного dispatch.
|
||||
|
||||
## Огляд конвеєра
|
||||
## Огляд pipeline
|
||||
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | Виявляє зміни лише в документації, змінені області, змінені розширення та будує CI-маніфест | Завжди для нечернеткових push і PR |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR |
|
||||
| `security-dependency-audit` | Аудит production lockfile без встановлення залежностей щодо npm advisories | Завжди для нечернеткових push і PR |
|
||||
| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для нечернеткових push і PR |
|
||||
| `check-dependencies` | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node |
|
||||
| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані артефакти для downstream | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Sharded-перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Шарди тестів Core Node, крім ліній каналів, bundled, contract і extension | Зміни, релевантні для Node |
|
||||
| `check` | Sharded-еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Шарди architecture, boundary, extension-surface guards, package-boundary і gateway-watch | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI і startup-memory smoke | Зміни, релевантні для Node |
|
||||
| `checks` | Верифікатор для тестів каналів зібраних артефактів | Зміни, релевантні для Node |
|
||||
| `checks-node-compat-node22` | Лінія збірки та smoke для сумісності з Node 22 | Ручний CI dispatch для релізів |
|
||||
| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для Python-backed skills | Зміни, релевантні для Python skills |
|
||||
| `checks-windows` | Специфічні для Windows тести процесів/шляхів плюс регресії shared runtime import specifier | Зміни, релевантні для Windows |
|
||||
| `macos-node` | Лінія TypeScript-тестів macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Unit-тести Android для обох flavors плюс одна збірка debug APK | Зміни, релевантні для Android |
|
||||
| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний dispatch |
|
||||
| `preflight` | Виявляє зміни лише в docs, змінені області, змінені extensions і будує CI manifest | Завжди для non-draft pushes і PRs |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft pushes і PRs |
|
||||
| `security-dependency-audit` | Production-аудит lockfile без dependencies за npm advisories | Завжди для non-draft pushes і PRs |
|
||||
| `security-fast` | Обов’язковий агрегат для швидких security jobs | Завжди для non-draft pushes і PRs |
|
||||
| `check-dependencies` | Production-прохід Knip лише для dependencies плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node |
|
||||
| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built artifacts і reusable downstream artifacts | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Core Node test shards, крім channel, bundled, contract і extension lanes | Зміни, релевантні для Node |
|
||||
| `check` | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke tests зібраного CLI і startup-memory smoke | Зміни, релевантні для Node |
|
||||
| `checks` | Verifier для built-artifact channel tests | Зміни, релевантні для Node |
|
||||
| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke lane | Ручний CI dispatch для релізів |
|
||||
| `check-docs` | Форматування docs, lint і перевірки broken links | Змінено docs |
|
||||
| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні для Python Skills |
|
||||
| `checks-windows` | Специфічні для Windows process/path tests плюс спільні regressions runtime import specifier | Зміни, релевантні для Windows |
|
||||
| `macos-node` | macOS TypeScript test lane із використанням спільних built artifacts | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Android unit tests для обох flavors плюс одна debug APK build | Зміни, релевантні для Android |
|
||||
| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після trusted activity | Успішний main CI або ручний 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` швидко завершуються з помилкою, не чекаючи важчих завдань матриці артефактів і платформ.
|
||||
3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати, щойно спільна збірка буде готова.
|
||||
4. Важчі платформні й 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` є кроками всередині цього завдання, а не окремими jobs.
|
||||
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 могли стартувати щойно спільна збірка буде готова.
|
||||
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 також не падає. Агреговані перевірки шардів використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні помилки шардів, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний ключ concurrency CI версійований (`CI-v7-*`), тож zombie з боку GitHub у старій групі черги не може безстроково блокувати новіші запуски main. Ручні запуски повного suite використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються.
|
||||
GitHub може позначати замінені jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний CI concurrency key версіонований (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безкінечно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують runs, що вже виконуються.
|
||||
|
||||
## Область і маршрутизація
|
||||
## Область і routing
|
||||
|
||||
Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує preflight-маніфест поводитися так, ніби змінилася кожна scoped-ділянка.
|
||||
Логіка області розміщена в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area.
|
||||
|
||||
- **Редагування CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не змушують виконувати native-збірки Windows, Android або macOS; ці платформні лінії залишаються обмеженими змінами платформного source.
|
||||
- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі редагування plugin contract helper/test-routing** використовують швидкий шлях маніфесту лише для Node: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність із Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові матриці guard, коли зміна обмежена routing або helper-поверхнями, які швидке завдання безпосередньо перевіряє.
|
||||
- **Windows Node checks** обмежені специфічними для Windows process/path wrappers, npm/pnpm/UI runner helpers, конфігурацією package manager і CI workflow-поверхнями, що виконують цю лінію; непов’язані зміни source, plugin, install-smoke і лише тестові зміни залишаються на Linux Node-лініях.
|
||||
- **Редагування CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються прив’язаними до змін platform source.
|
||||
- **Редагування лише CI routing, вибрані дешеві редагування core-test fixtures і вузькі редагування plugin contract helper/test-routing** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, сумісність із Node 22, channel contracts, повні core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму.
|
||||
- **Windows Node checks** обмежені специфічними для Windows process/path wrappers, npm/pnpm/UI runner helpers, package manager config і поверхнями CI workflow, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lanes.
|
||||
|
||||
Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts виконуються як три зважені шарди, малі core unit-лінії спарені, auto-reply виконується як чотири збалансовані workers (із розділенням reply subtree на шарди agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування build artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням імені CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині одного job. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
|
||||
Найповільніші сімейства Node tests розділені або збалансовані, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes об’єднані парами, auto-reply запускається як чотири збалансовані workers (із reply subtree, розділеним на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі 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` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині одного job. 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 з BuildConfig flags для SMS/call-log, водночас уникаючи дубльованого debug APK packaging job для кожного Android-relevant push.
|
||||
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з прапорцями SMS/call-log BuildConfig, водночас уникаючи дублювання debug APK packaging job на кожному Android-relevant push.
|
||||
|
||||
Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на найновішій версії Knip, із вимкненим мінімальним віком релізу pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
|
||||
Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production-прохід Knip лише для dependencies, закріплений на найновішій версії Knip, із вимкненим мінімальним віком release для pnpm під час `dlx` install) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може розв’язати статично.
|
||||
|
||||
## Ручні dispatch
|
||||
## Ручні dispatches
|
||||
|
||||
Ручні CI dispatch запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped-лінію, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі ручні CI dispatch запускають Android лише з `include_android=true`; повна release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatch окремого workflow `Plugin Prerelease` з увімкненим release-validation gate.
|
||||
Ручні CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожну non-Android scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі ручні CI dispatches запускають Android лише з `include_android=true`; повна release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatches окремий workflow `Plugin Prerelease` із увімкненим release-validation gate.
|
||||
|
||||
Ручні запуски використовують унікальну concurrency group, тому повний suite реліз-кандидата не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає довіреному викликачеві змогу запустити цей граф для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
|
||||
Ручні runs використовують унікальну concurrency group, щоб release-candidate full suite не було скасовано іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає змогу trusted caller запустити цей граф для branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref.
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref release/YYYY.M.D
|
||||
@ -79,17 +79,17 @@ 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`), швидкі перевірки протоколу/контрактів/вбудованих компонентів, сегментовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; попередня перевірка install-smoke також використовує Ubuntu, розміщений на GitHub, щоб матриця 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, шарди тестів вбудованих плагінів, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували дорожче, ніж заощаджували); Docker-збірки install-smoke (час у черзі для 32-vCPU коштував дорожче, ніж заощаджував) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| Виконавець | Завдання |
|
||||
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контракту/вбудованих компонентів, сегментовані перевірки контрактів каналів, сегменти `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`, легші сегменти Plugin, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, сегменти тестів Linux Node, сегменти тестів вбудованих plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час очікування в черзі для 32 vCPU коштував більше, ніж заощаджував) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
|
||||
## Локальні відповідники
|
||||
## Локальні еквіваленти
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # inspect the local changed-lane classifier for origin/main...HEAD
|
||||
@ -117,39 +117,37 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
|
||||
## Повна перевірка релізу
|
||||
|
||||
`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження плагінів/пакетів/статичних ресурсів/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` з артефактом `release-package-under-test` із перевірок релізу. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm-пакета.
|
||||
`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізних доказів plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram-ліній. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти артефакту `release-package-under-test` із release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму лінію пакета Telegram проти опублікованого npm-пакета.
|
||||
|
||||
Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для
|
||||
матриці етапів, точних назв завдань workflow, відмінностей профілів, артефактів і
|
||||
дескрипторів цільового повторного запуску.
|
||||
точкових ідентифікаторів повторного запуску.
|
||||
|
||||
`release_profile` керує широтою live/provider, переданою в перевірки релізу. Ручні
|
||||
релізні workflow типово використовують `stable`; використовуйте `full` лише тоді, коли
|
||||
навмисно потрібна широка дорадча матриця провайдерів/медіа.
|
||||
`release_profile` керує шириною live/provider, переданою в release checks. Ручні release workflows типово використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка advisory-матриця provider/media.
|
||||
|
||||
- `minimum` залишає найшвидші критичні для релізу OpenAI/core lanes.
|
||||
- `minimum` залишає найшвидші критичні для релізу лінії OpenAI/core.
|
||||
- `stable` додає стабільний набір provider/backend.
|
||||
- `full` запускає широку дорадчу матрицю провайдерів/медіа.
|
||||
- `full` запускає широку advisory-матрицю provider/media.
|
||||
|
||||
Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено й він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок часу.
|
||||
Парасольковий workflow записує ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow перезапустили й він став зеленим, перезапустіть лише батьківське завдання-верифікатор, щоб оновити результат парасолькового workflow і підсумок часу.
|
||||
|
||||
Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата на реліз, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього prerelease плагінів, `release-checks` для кожного дочірнього релізного workflow або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це зберігає повторний запуск невдалої релізної машини обмеженим після цільового виправлення.
|
||||
Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для звичайного дочірнього full CI, `plugin-prerelease` лише для дочірнього plugin prerelease, `release-checks` для кожного release child або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольковому workflow. Це утримує повторний запуск невдалого release box у межах після точкового виправлення.
|
||||
|
||||
`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в шард package acceptance. Це зберігає байти пакета узгодженими між релізними машинами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
|
||||
`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в сегмент package acceptance. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
|
||||
|
||||
Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all`
|
||||
замінюють старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який
|
||||
він уже запустив, коли батьківський workflow скасовано, тому новіша перевірка main
|
||||
не стоїть позаду застарілого двогодинного прогону release-check. Перевірка релізної гілки/тега
|
||||
й цільові групи повторного запуску залишають `cancel-in-progress: false`.
|
||||
Дубльовані запуски `Full Release Validation` для `ref=main` і `rerun_group=all`
|
||||
замінюють старіший парасольковий workflow. Батьківський монітор скасовує будь-який дочірній workflow, який
|
||||
він уже запустив, коли батьківський скасовано, тому новіша перевірка main
|
||||
не стоїть за застарілим двогодинним запуском release-check. Перевірка гілки/тега релізу
|
||||
і точкові групи повторного запуску залишають `cancel-in-progress: false`.
|
||||
|
||||
## Live та E2E шарди
|
||||
## Live та E2E-сегменти
|
||||
|
||||
Дочірній live/E2E для релізу зберігає широке нативне покриття `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`
|
||||
- завдання `native-live-src-gateway-profiles`, відфільтровані за provider
|
||||
- provider-filtered завдання `native-live-src-gateway-profiles`
|
||||
- `native-live-src-gateway-backends`
|
||||
- `native-live-test`
|
||||
- `native-live-extensions-a-k`
|
||||
@ -157,61 +155,61 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
- `native-live-extensions-openai`
|
||||
- `native-live-extensions-o-z-other`
|
||||
- `native-live-extensions-xai`
|
||||
- розділені шарди audio/video для медіа та шарди music, відфільтровані за provider
|
||||
- розділені сегменти media audio/video і provider-filtered music segments
|
||||
|
||||
Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних 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` залишаються чинними для ручних одноразових повторних запусків.
|
||||
|
||||
Нативні live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; медіа-завдання лише перевіряють двійкові файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних виконавцях Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker-тестів.
|
||||
Нативні live media segments працюють у `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker tests.
|
||||
|
||||
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 шарди мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, релізний прогін налаштовано неправильно, і він марнуватиме реальний час на дублікати збірок образів.
|
||||
Docker-backed live model/backend shards використовують окремий спільний образ `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 shards мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці сегменти незалежно перебудовують повну source Docker target, release run налаштовано неправильно, і він марнуватиме час на дубльовані збірки образів.
|
||||
|
||||
## Package Acceptance
|
||||
## Прийняття пакета
|
||||
|
||||
Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі проходять після встановлення або оновлення.
|
||||
Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей встановлюваний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі запускають після встановлення або оновлення.
|
||||
|
||||
### Завдання
|
||||
|
||||
1. `resolve_package` перевіряє `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, посилання workflow, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub.
|
||||
2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лінії для цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow один раз готує пакет і спільні образи, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
|
||||
3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance визначив його; окремий запуск Telegram усе ще може встановити опубліковану специфікацію npm.
|
||||
4. `summary` завершує workflow з помилкою, якщо визначення пакета, Docker-приймання або опційна лінія Telegram завершилися невдало.
|
||||
1. `resolve_package` виконує checkout `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, ref workflow, ref пакета, версію, SHA-256 і профіль у підсумку кроку GitHub.
|
||||
2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи з дайджестом пакета й запускає вибрані Docker-лінії проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
|
||||
3. `package_telegram` опціонально викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance визначив його; автономний запуск Telegram все ще може встановити опубліковану npm-специфікацію.
|
||||
4. `summary` завершує workflow з помилкою, якщо визначення пакета, Docker acceptance або опціональна лінія Telegram завершилися невдало.
|
||||
|
||||
### Джерела кандидатів
|
||||
|
||||
- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable.
|
||||
- `source=ref` пакує довірену гілку `package_ref`, тег або повний SHA коміту. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт доступний з історії гілки репозиторію або релізного тегу, встановлює залежності у відокремленому worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованих beta/stable.
|
||||
- `source=ref` пакує довірену гілку `package_ref`, тег або повний commit SHA. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний commit досяжний з історії гілок репозиторію або release tag, встановлює залежності в від’єднаному worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим.
|
||||
- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` є опційним, але його варто надати для зовнішньо поширених артефактів.
|
||||
- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` опціональний, але його варто вказувати для артефактів, якими діляться зовні.
|
||||
|
||||
Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/тестового harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старі довірені вихідні коміти без запуску старої логіки workflow.
|
||||
Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старі довірені source commits без запуску старої логіки workflow.
|
||||
|
||||
### Профілі наборів
|
||||
### Профілі 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-шляху релізу з OpenWebUI
|
||||
- `full` — повні Docker-фрагменти release path з OpenWebUI
|
||||
- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
|
||||
|
||||
Профіль `package` використовує offline-покриття Plugin, щоб перевірка опублікованого пакета не залежала від live-доступності ClawHub. Опційна лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої специфікації npm збережено для окремих запусків.
|
||||
Профіль `package` використовує offline-покриття Plugin, щоб перевірка опублікованого пакета не залежала від live-доступності ClawHub. Опціональна лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації лишається для автономних запусків.
|
||||
|
||||
Для спеціальної політики тестування оновлень і Plugin, включно з локальними командами,
|
||||
Docker-лініями, вхідними параметрами Package Acceptance, типовими параметрами релізу та тріажем збоїв,
|
||||
Щодо спеціальної політики тестування оновлень і Plugin, включно з локальними командами,
|
||||
Docker-лініями, входами Package Acceptance, типовими параметрами релізу та triage помилок,
|
||||
див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins).
|
||||
|
||||
Перевірки релізу викликають Package Acceptance з `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає перевірку міграції пакета, оновлення, очищення застарілих залежностей Plugin, offline Plugin, plugin-update і Telegram на одному й тому самому визначеному tarball пакета. Cross-OS перевірки релізу й надалі покривають специфічні для ОС onboarding, installer і поведінку платформи; перевірка продукту для пакета/оновлення має починатися з Package Acceptance. Docker-лінія `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback baseline опублікованого пакета, за замовчуванням `openclaw@latest`; команди повторного запуску лінії, що впала, зберігають цей baseline. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розширити лінію на дедупліковану матрицю історії: шість останніх stable-релізів, `2026.4.23` і останній stable-реліз перед `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-подібні fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, шляхів логів із тильдою та застарілих коренів залежностей legacy Plugin. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `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. Smoke OpenAI cross-OS agent-turn за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його встановлено, інакше `openai/gpt-5.5`, тож перевірка встановлення й gateway лишається на бажаній тестовій моделі GPT-5.
|
||||
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=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає перевірки міграції пакета, оновлення, очищення застарілих Plugin-залежностей, offline Plugin, plugin-update і Telegram на тому самому визначеному tarball пакета. Cross-OS release checks все ще покривають OS-специфічні onboarding, installer і поведінку платформи; product-перевірку package/update слід починати з Package Acceptance. Docker-лінія `published-upgrade-survivor` перевіряє одну опубліковану базову версію пакета за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опубліковану базову версію, типово `openclaw@latest`; команди повторного запуску failed lane зберігають цю базову версію. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розгорнути лінію по deduped матриці історії: останні шість stable releases, `2026.4.23` і останній stable release перед `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розгорнути ті самі базові версії по issue-подібних fixtures для конфігурації Feishu, збережених bootstrap/persona файлів, tilde шляхів логів і застарілих legacy коренів Plugin-залежностей. Окремий workflow `Update Migration` використовує Docker-лінію `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованих оновлень, а не у звичайній ширині Full Release CI. Локальні aggregate-запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, залишати одну лінію з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, як-от `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована лінія налаштовує базову версію за допомогою baked recipe команди `openclaw config set`, записує кроки recipe у `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh лінії також перевіряють, що встановлений пакет може імпортувати browser-control override з raw absolute Windows path. Cross-OS agent-turn smoke для OpenAI типово використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його задано, інакше `openai/gpt-5.5`, тому proof встановлення й Gateway лишається на бажаній тестовій моделі GPT-5.
|
||||
|
||||
### Вікна legacy-сумісності
|
||||
|
||||
Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
|
||||
|
||||
- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
|
||||
- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
|
||||
- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із фіктивного git fixture, похідного від tarball, і може логувати відсутній збережений `update.channel`;
|
||||
- smoke-перевірки Plugin можуть читати legacy-розташування install-record або приймати відсутнє збереження marketplace install-record;
|
||||
- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка без повторного встановлення лишалися незмінними.
|
||||
- `doctor-switch` може пропустити підвипадок persistence `gateway install --wrapper`, коли пакет не надає цей flag;
|
||||
- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній persist `update.channel`;
|
||||
- plugin smokes можуть читати legacy locations install-record або приймати відсутню persistence marketplace install-record;
|
||||
- `plugin-update` може дозволити міграцію config metadata, водночас все ще вимагаючи, щоб install record і поведінка no-reinstall лишалися незмінними.
|
||||
|
||||
Опублікований пакет `2026.4.26` також може попереджати про файли stamp локальних build-метаданих, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови призводять до помилки замість попередження або пропуску.
|
||||
Опублікований пакет `2026.4.26` також може попереджати про локальні stamp files build metadata, які вже були shipped. Пізніші пакети мають задовольняти сучасні contracts; ті самі умови завершуються failure, а не warn або skip.
|
||||
|
||||
### Приклади
|
||||
|
||||
@ -254,111 +252,111 @@ gh workflow run package-acceptance.yml \
|
||||
-f docker_lanes='install-e2e plugin-update'
|
||||
```
|
||||
|
||||
Під час налагодження невдалого запуску package acceptance починайте з підсумку `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`, логи ліній, phase timings і команди повторного запуску. Надавайте перевагу повторному запуску failed package profile або точних Docker-ліній замість повторного запуску повної release validation.
|
||||
|
||||
## Install smoke
|
||||
|
||||
Окремий workflow `Install Smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
|
||||
|
||||
- **Швидкий шлях** запускається для pull requests, що торкаються Docker/package-поверхонь, змін пакета/маніфесту bundled Plugin або core-поверхонь plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо).
|
||||
- **Повний шлях** зберігає покриття QR package install і installer Docker/update для нічних планових запусків, ручних запусків, workflow-call перевірок релізу та pull requests, які справді торкаються installer/package/Docker-поверхонь. У повному режимі install-smoke готує або повторно використовує один GHCR root Dockerfile smoke-образ для target-SHA, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб installer-робота не чекала за smoke-перевірками root image.
|
||||
- **Швидкий шлях** запускається для pull requests, що торкаються Docker/package surfaces, змін bundled plugin package/manifest або core plugin/channel/gateway/Plugin SDK surfaces, які виконують Docker smoke jobs. Зміни лише source у bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє bundled extension build arg і запускає bounded bundled-plugin Docker profile у межах aggregate command timeout 240 секунд (Docker-запуск кожного сценарію обмежений окремо).
|
||||
- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді торкаються installer/package/Docker surfaces. У full mode install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і fast bundled-plugin Docker E2E як окремі jobs, щоб installer work не чекала за root image smokes.
|
||||
|
||||
Push до `main` (зокрема merge commits) не примушують повний шлях; коли логіка changed-scope вимагала б повного покриття на push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної перевірки.
|
||||
`main` pushes (зокрема merge commits) не примушують full path; коли changed-scope logic запитала б full coverage на push, workflow залишає fast Docker smoke, а full install smoke лишає нічній або release validation.
|
||||
|
||||
Повільний smoke image-provider для глобального встановлення Bun окремо контролюється `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `Install Smoke` можуть увімкнути його, але pull requests і push до `main` — ні. QR і installer Docker-тести зберігають власні install-focused Dockerfiles.
|
||||
Повільний Bun global install image-provider smoke окремо gated через `run_bun_global_install_smoke`. Він запускається за nightly schedule і з release checks workflow, а manual dispatches `Install Smoke` можуть увімкнути його, але pull requests і `main` pushes — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
|
||||
|
||||
## Локальний Docker E2E
|
||||
|
||||
`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
|
||||
`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
|
||||
|
||||
- bare Node/Git runner для ліній installer/update/plugin-dependency;
|
||||
- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
|
||||
- functional image, який встановлює той самий tarball у `/app` для звичайних functionality 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-ліній розташовані в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає образ для кожної лінії через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
|
||||
### Налаштування
|
||||
### Параметри налаштування
|
||||
|
||||
| Змінна | Типове значення | Призначення |
|
||||
| -------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу, чутливого до провайдерів. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live-ліній, щоб провайдери не вмикали обмеження. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних ліній встановлення npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних багатосервісних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між запусками ліній, щоб уникнути штормів створення в демоні Docker; задайте `0`, щоб вимкнути затримку. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут для кожної лінії (120 хвилин); вибрані live/хвостові лінії використовують жорсткіші ліміти. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | не задано | `1` друкує план планувальника без запуску ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | не задано | Розділений комами точний список ліній; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу лінію. |
|
||||
| Змінна | Типово | Призначення |
|
||||
| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу, чутливого до провайдерів. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження одночасних live-ліній, щоб провайдери не застосовували throttling. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження одночасних ліній встановлення npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження одночасних багатосервісних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникнути сплесків створення в 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, щоб агенти могли відтворити одну невдалу лінію. |
|
||||
|
||||
Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Локальний агрегатор попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E-контейнери, виводить статус активних ліній, зберігає тривалості ліній для впорядкування від найдовших і типово припиняє планування нових pooled-ліній після першого збою.
|
||||
Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальний агрегатор попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E-контейнери, виводить статус активних ліній, зберігає тривалості ліній для впорядкування від найдовших до найкоротших і типово припиняє планувати нові pooled-лінії після першої помилки.
|
||||
|
||||
### Багаторазовий live/E2E workflow
|
||||
|
||||
Багаторазовий live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, які пакет, тип образу, live-образ, лінія та покриття обліковими даними потрібні. `scripts/docker-e2e.mjs` потім перетворює цей план на виходи й підсумки GitHub. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та публікує bare/functional GHCR Docker E2E-образи з тегами package-digest через кеш Docker-шарів Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи package-digest замість повторного збирання. Завантаження Docker-образів повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI.
|
||||
Багаторазовий live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і підсумки. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє inventory tarball; збирає й публікує GHCR Docker E2E-образи bare/functional із тегами за digest пакета через кеш Docker-шарів Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи за digest пакета замість повторної збірки. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторився, а не спожив більшість критичного шляху CI.
|
||||
|
||||
### Фрагменти release-шляху
|
||||
### Фрагменти release-path
|
||||
|
||||
Release Docker-покриття запускає менші фрагментовані job з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний тип образу й виконував кілька ліній через той самий зважений планувальник:
|
||||
Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник:
|
||||
|
||||
- `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
|
||||
- `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h`
|
||||
|
||||
Поточні release Docker-фрагменти: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і `plugins-runtime-install-a` through `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох ліній 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` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається агрегованим ручним псевдонімом повторного запуску для обох ліній installer провайдерів.
|
||||
|
||||
OpenWebUI включається до `plugins-runtime-services`, коли повне release-path-покриття його запитує, і зберігає окремий фрагмент `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення bundled-channel повторюють спробу один раз у разі тимчасових мережевих збоїв npm.
|
||||
OpenWebUI включається в `plugins-runtime-services`, коли повне release-path coverage цього потребує, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення bundled-channel повторюють спробу один раз для тимчасових мережевих помилок npm.
|
||||
|
||||
Кожен фрагмент вивантажує `.artifacts/docker-tests/` з логами ліній, тривалостями, `summary.json`, `failures.json`, тривалостями фаз, JSON-планом планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Вхід `docker_lanes` workflow запускає вибрані лінії проти підготовлених образів замість fragment jobs, що обмежує налагодження невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільовий job збирає live-test-образ локально для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і підготовлені входи образів, коли такі значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску.
|
||||
Кожен chunk завантажує `.artifacts/docker-tests/` з журналами ліній, тривалостями, `summary.json`, `failures.json`, тривалостями фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує налагодження невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker lane, цільовий job локально збирає live-test image для цього повторного запуску. Згенеровані GitHub-команди повторного запуску для кожної лінії включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли такі значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску.
|
||||
|
||||
```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
|
||||
pnpm test:docker:rerun <run-id> # завантажити Docker-артефакти й надрукувати combined/per-lane цільові команди повторного запуску
|
||||
pnpm test:docker:timings <summary> # підсумки повільних ліній і критичного шляху фаз
|
||||
```
|
||||
|
||||
Запланований live/E2E workflow щодня запускає повний Docker-набір release-path.
|
||||
Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
|
||||
|
||||
## Попередній випуск Plugin
|
||||
## Plugin Prerelease
|
||||
|
||||
`Plugin Prerelease` є дорожчим продуктово-пакетним покриттям, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і самостійні ручні CI dispatch не вмикають цей набір. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох груп конфігурацій Plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети Plugin не створювали додаткових CI jobs. Release-only Docker prerelease path групує цільові Docker-лінії в малі групи, щоб не резервувати десятки runners для job тривалістю від однієї до трьох хвилин.
|
||||
`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається через `Full Release Validation` або явним оператором. Звичайні pull requests, push у `main` і окремі manual CI dispatches не запускають цей suite. Він балансує тести bundled plugin між вісьмома extension workers; ці jobs шард extension запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети plugin не створювали додаткових CI jobs. Release-only Docker prerelease path групує цільові Docker lanes невеликими наборами, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин.
|
||||
|
||||
## QA Lab
|
||||
|
||||
QA Lab має виділені CI-лінії поза основним smart-scoped workflow.
|
||||
QA Lab має dedicated CI lanes поза основним smart-scoped workflow.
|
||||
|
||||
- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6.
|
||||
- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгортає mock parity gate, live Matrix lane і live Telegram та Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
|
||||
- Workflow `Parity gate` запускається на відповідних змінах PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs.
|
||||
- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгалужує mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
|
||||
|
||||
Release checks запускають live transport lanes Matrix і Telegram із детермінованим mock-провайдером та mock-qualified моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від live model latency і звичайного startup provider-plugin. Live transport gateway вимикає пошук памʼяті, бо QA parity окремо покриває поведінку памʼяті; підключення провайдера покривається окремими наборами live model, native provider і Docker provider.
|
||||
Release checks запускають Matrix і Telegram live transport lanes із deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від latency live model і звичайного startup provider-plugin. Live transport gateway вимикає memory search, тому що QA parity окремо покриває поведінку пам’яті; provider connectivity покривається окремими suites live model, native provider і Docker provider.
|
||||
|
||||
Matrix використовує `--profile fast` для запланованих і release gates, додаючи `--fail-fast` лише коли checkout CLI це підтримує. Типове значення CLI та вхід ручного workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix-покриття на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
|
||||
Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Типове значення CLI і manual workflow input залишаються `all`; manual `matrix_profile=all` dispatch завжди шардує повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
|
||||
|
||||
`OpenClaw Release Checks` також запускає критичні для release лінії QA Lab перед затвердженням release; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в малий report job для фінального parity comparison.
|
||||
`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, потім завантажує обидва артефакти в невеликий report job для фінального parity comparison.
|
||||
|
||||
Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test розглядайте це як optional signal і спирайтеся на scoped CI/check evidence.
|
||||
Не ставте PR landing path за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, model-pack parity або surface, яким володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test розглядайте це як optional signal і натомість спирайтеся на scoped CI/check evidence.
|
||||
|
||||
## CodeQL
|
||||
|
||||
Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Щоденні, ручні та non-draft pull request guard runs сканують код Actions workflow плюс JavaScript/TypeScript-поверхні найвищого ризику за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`.
|
||||
Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним repository sweep. Daily, manual і non-draft pull request guard runs сканують код Actions workflow плюс найризикованіші JavaScript/TypeScript surfaces з high-confidence security queries, відфільтрованими до high/critical `security-severity`.
|
||||
|
||||
Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків.
|
||||
Pull request guard лишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять у PR defaults.
|
||||
|
||||
### Категорії безпеки
|
||||
|
||||
| Категорія | Поверхня |
|
||||
| Категорія | Surface |
|
||||
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і gateway baseline |
|
||||
| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і baseline gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс channel plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP parsing, network guard, web-fetch і поверхні політики SSRF у Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і agent tool-execution gates |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust surfaces контракту package у Plugin SDK |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP parsing, network guard, web-fetch і surfaces політики SSRF Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і gates agent tool-execution |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust surfaces контракту пакета Plugin SDK |
|
||||
|
||||
### Платформоспецифічні security shards
|
||||
### Platform-specific 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` — scheduled Android security shard. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — weekly/manual macOS security shard. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує dependency build results із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Тримається поза daily defaults, тому що macOS build домінує runtime навіть у чистому стані.
|
||||
|
||||
### Категорії Critical Quality
|
||||
|
||||
`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries по вузьких high-value поверхнях на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за запланований профіль: non-draft PRs запускають лише відповідні 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` є відповідним non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries по вузьких high-value surfaces на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за scheduled profile: non-draft PRs запускають лише відповідні 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 execution і reply dispatch, config schema/migration/IO code, auth/secrets/sandbox/security code, core channel і bundled channel plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards.
|
||||
|
||||
Manual dispatch приймає:
|
||||
|
||||
@ -366,40 +364,40 @@ Manual dispatch приймає:
|
||||
profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
```
|
||||
|
||||
Вузькі профілі є hooks для навчання/ітерації, щоб запускати один quality shard ізольовано.
|
||||
Вузькі profiles є teaching/iteration hooks для запуску одного quality shard в ізоляції.
|
||||
|
||||
| Категорія | Поверхня |
|
||||
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Auth, секрети, sandbox, Cron і код межі безпеки Gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та контракти IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти серверних методів |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та bundled channel plugin |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація та черги автовідповідей, а також runtime-контракти control plane ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP і tool bridges, помічники нагляду за процесами та контракти outbound delivery |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, runtime-фасади пам’яті, псевдоніми memory Plugin SDK, glue-код активації memory runtime та команди memory doctor |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня реалізація черги відповідей, черги доставки сесій, помічники прив’язки/доставки outbound-сесій, поверхні діагностичних подій/log bundle і контракти CLI session doctor |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, помічники payload/chunking/runtime відповідей, параметри відповідей каналів, черги доставки та помічники прив’язки сесій/потоків |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та discovery провайдерів, реєстрація provider runtime, provider defaults/catalogs, а також реєстри web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Bootstrap Control UI, локальна персистентність, control flows Gateway і runtime-контракти task control-plane |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Runtime-контракти core web fetch/search, media IO, media understanding, image-generation та media-generation |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, public-surface і entrypoint Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і помічники контрактів package plugin |
|
||||
| Категорія | Поверхня |
|
||||
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Auth, секрети, 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` | Внутрішня логіка черги відповідей, черги доставки сесій, допоміжні засоби прив’язування/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI doctor для сесій |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, допоміжні засоби payload/фрагментації/runtime для відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування сесій/тредів |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, auth і виявлення провайдерів, реєстрація 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, медіа IO, розуміння медіа, генерації зображень і генерації медіа |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковане вихідне дерево Plugin SDK з боку пакета та допоміжні засоби контрактів пакетів Plugin |
|
||||
|
||||
Якість залишається відокремленою від безпеки, щоб висновки щодо якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
|
||||
Якість залишається окремо від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати, не затіняючи сигнал безпеки. Розширення CodeQL для Swift, Python і вбудованих Plugin слід додавати назад як scoped або shard подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
|
||||
|
||||
## Робочі процеси обслуговування
|
||||
|
||||
### Docs Agent
|
||||
|
||||
Робочий процес `Docs Agent` — це керована подіями maintenance lane Codex для підтримання наявної документації у відповідності з нещодавно доданими змінами. Він не має чистого розкладу: успішний CI-запуск після push не від bot на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший не пропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього не пропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
|
||||
Робочий процес `Docs Agent` — це подієва смуга обслуговування Codex для підтримання наявної документації у відповідності до нещодавно приземлених змін. Він не має чистого розкладу: успішний CI-запуск після небот-пушу в `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики від workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено за останню годину. Коли він запускається, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тому один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
|
||||
|
||||
### Test Performance Agent
|
||||
|
||||
Робочий процес `Test Performance Agent` — це керована подіями maintenance lane Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск після push не від bot на `main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей daily activity gate. Lane будує повний grouped Vitest performance report для всього набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, які зменшують baseline count успішних тестів. Якщо baseline має failing tests, Codex може виправити лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким commit. Коли `main` просувається до того, як bot push буде додано, lane rebases перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex міг зберегти ту саму drop-sudo safety posture, що й docs agent.
|
||||
Робочий процес `Test Performance Agent` — це подієва смуга обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск після небот-пушу в `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей щоденний шлюз активності. Смуга створює згрупований звіт продуктивності Vitest для повного набору тестів, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість прохідних тестів. Якщо базова лінія має тести, що падають, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти перед комітом будь-чого. Коли `main` просувається до приземлення bot push, смуга робить rebase перевіреного патча, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі патчі пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб action Codex міг зберігати таку саму безпечну позицію drop-sudo, як і docs agent.
|
||||
|
||||
### Дублікати PR після merge
|
||||
|
||||
Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після land. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR merged і що кожен duplicate має або спільну referenced issue, або overlapping changed hunks.
|
||||
Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після приземлення. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що приземлений PR змержено і що кожен дублікат має або спільне referenced issue, або перетин змінених hunks.
|
||||
|
||||
```bash
|
||||
gh workflow run duplicate-after-merge.yml \
|
||||
@ -410,27 +408,27 @@ gh workflow run duplicate-after-merge.yml \
|
||||
|
||||
## Локальні check gates і changed routing
|
||||
|
||||
Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий scope платформи CI:
|
||||
Логіка локальних changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий 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 changes розширюються до 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.
|
||||
- зміни core production запускають core prod і core test typecheck плюс core lint/guards;
|
||||
- зміни лише core test запускають тільки core test typecheck плюс core lint;
|
||||
- зміни extension production запускають extension prod і extension test typecheck плюс extension lint;
|
||||
- зміни лише extension test запускають extension test typecheck плюс extension lint;
|
||||
- зміни публічного Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною тестовою роботою);
|
||||
- version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
|
||||
- невідомі root/config changes fail safe до всіх check lanes.
|
||||
|
||||
Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі 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 зазнав failure перед першим PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли change достатньо harness-wide, що дешевий mapped set не є надійним proxy.
|
||||
Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі редагування тестів запускають самі себе, редагування source віддають перевагу явним mappings, потім sibling tests і dependents import-graph. Конфігурація доставки shared group-room є одним із явних 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
|
||||
## Валідація Testbox
|
||||
|
||||
Запускайте Testbox з repo root і віддавайте перевагу свіжому warmed box для broad proof. Перш ніж витрачати повільний gate на box, який було reused, expired або який щойно повідомив про неочікувано великий sync, спочатку запустіть `pnpm testbox:sanity` всередині box.
|
||||
Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжому warmed box для широкого proof. Перш ніж витрачати повільний gate на box, який було повторно використано, термін дії якого минув або який щойно повідомив про несподівано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box.
|
||||
|
||||
Sanity check fails fast, коли обов’язкові root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і warm a fresh one замість налагодження product test failure. Для навмисних large-deletion PR встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
|
||||
Sanity check швидко падає, коли зникають обов’язкові root files на кшталт `pnpm-lock.yaml` або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цей box і прогрійте свіжий замість налагодження product test failure. Для PR з навмисними large-deletion встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
|
||||
|
||||
`pnpm testbox:run` також завершує локальний Blacksmith CLI invocation, який залишається у sync phase понад п’ять хвилин без post-sync output. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих local diffs.
|
||||
`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без post-sync output. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих local diffs.
|
||||
|
||||
Crabbox — це repo-owned другий remote-box path для Linux proof, коли Blacksmith недоступний або коли owned cloud capacity є кращою. Warm a box, hydrate його через project workflow, потім запускайте команди через Crabbox CLI:
|
||||
Crabbox — це другий remote-box шлях, що належить репозиторію, для Linux proof, коли Blacksmith недоступний або коли бажано використати власну cloud capacity. Прогрійте box, hydrate його через project workflow, потім запускайте команди через Crabbox CLI:
|
||||
|
||||
```bash
|
||||
pnpm crabbox:warmup -- --idle-timeout 90m
|
||||
@ -439,7 +437,7 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
|
||||
pnpm crabbox:stop -- <cbx_id>
|
||||
```
|
||||
|
||||
`.crabbox.yaml` керує provider, sync і GitHub Actions hydration defaults. Він виключає локальний `.git`, щоб hydrated Actions checkout зберігав власні remote Git metadata замість syncing maintainer-local remotes і object stores, а також виключає local runtime/build artifacts, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` керує checkout, налаштуванням Node/pnpm, fetch `origin/main` і non-secret environment handoff, який пізніші команди `crabbox run --id <cbx_id>` source.
|
||||
`.crabbox.yaml` містить стандартні налаштування provider, sync і GitHub Actions hydration. Він виключає локальний `.git`, щоб hydrated Actions checkout зберігав власні remote Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build artifacts, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` відповідає за checkout, налаштування Node/pnpm, fetch `origin/main` і non-secret environment handoff, який пізніші команди `crabbox run --id <cbx_id>` використовують як source.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
|
||||
@ -1,51 +1,52 @@
|
||||
---
|
||||
read_when:
|
||||
- Зміна поведінки оновлення OpenClaw, doctor, приймання пакетів або встановлення Plugin
|
||||
- Підготовка або затвердження реліз-кандидата
|
||||
- Налагодження оновлення пакета, очищення залежностей Plugin або регресій встановлення Plugin
|
||||
- Підготовка або схвалення реліз-кандидата
|
||||
- Налагодження оновлення пакета, очищення залежностей Plugin або регресій установлення Plugin
|
||||
sidebarTitle: Update and plugin tests
|
||||
summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення/оновлення Plugin
|
||||
summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення та оновлення Plugin
|
||||
title: 'Тестування: оновлення та Plugin'
|
||||
x-i18n:
|
||||
generated_at: "2026-05-01T22:37:35Z"
|
||||
generated_at: "2026-05-01T23:38:43Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: dc3cfa7b6a1ede28dfb12940b56d34d3f8ca4d539c26fd818d663d7052f962a8
|
||||
source_hash: 4d4b52047b9b80273e2d93b97e647e5e9c93d93910828fdce010568f3ea81390
|
||||
source_path: help/testing-updates-plugins.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Це окремий контрольний список для перевірки оновлень і плагінів. Мета
|
||||
проста: довести, що інстальований пакет може оновлювати реальний стан користувача,
|
||||
виправляти застарілий legacy-стан через `doctor` і надалі встановлювати,
|
||||
завантажувати, оновлювати та видаляти плагіни з підтримуваних джерел.
|
||||
Це спеціальний контрольний список для валідації оновлень і Plugin. Мета
|
||||
проста: довести, що інстальований пакет може оновити реальний стан користувача,
|
||||
відновити застарілий успадкований стан через `doctor` і все ще встановлювати,
|
||||
завантажувати, оновлювати та видаляти plugins із підтримуваних джерел.
|
||||
|
||||
Ширшу мапу тестового раннера див. у [Тестування](/uk/help/testing). Про live-ключі
|
||||
провайдерів і набори, що звертаються до мережі, див. [Live-тестування](/uk/help/testing-live).
|
||||
Ширшу карту тестового раннера див. у [Тестування](/uk/help/testing). Про ключі
|
||||
live-провайдерів і набори тестів, що торкаються мережі, див.
|
||||
[Live-тестування](/uk/help/testing-live).
|
||||
|
||||
## Що ми захищаємо
|
||||
|
||||
Тести оновлень і плагінів захищають такі контракти:
|
||||
Тести оновлення та Plugin захищають такі контракти:
|
||||
|
||||
- Tarball пакета повний, має чинний `dist/postinstall-inventory.json` і не
|
||||
залежить від розпакованих файлів репозиторію.
|
||||
- Користувач може перейти зі старішого опублікованого пакета на пакет-кандидат
|
||||
без втрати конфігурації, агентів, сесій, робочих просторів, allowlist плагінів
|
||||
або конфігурації каналів.
|
||||
- `openclaw doctor --fix --non-interactive` відповідає за legacy-очищення та
|
||||
шляхи відновлення. Startup не має нарощувати приховані міграції сумісності для
|
||||
застарілого стану плагінів.
|
||||
- Встановлення плагінів працює з локальних директорій, git-репозиторіїв, npm-пакетів
|
||||
і шляху реєстру ClawHub.
|
||||
- npm-залежності плагінів встановлюються в керований npm root, скануються перед
|
||||
довірою і видаляються через npm під час uninstall, щоб hoisted-залежності не
|
||||
лишалися.
|
||||
- Оновлення плагіна стабільне, коли нічого не змінилося: записи встановлення,
|
||||
resolved source і стан enabled лишаються неушкодженими.
|
||||
- Користувач може перейти зі старішого опублікованого пакета на кандидатний
|
||||
пакет без втрати конфігурації, агентів, сесій, робочих просторів, allowlist
|
||||
Plugin або конфігурації каналу.
|
||||
- `openclaw doctor --fix --non-interactive` володіє шляхами очищення та
|
||||
відновлення успадкованого стану. Startup не має розростатися прихованими
|
||||
міграціями сумісності для застарілого стану Plugin.
|
||||
- Встановлення Plugin працює з локальних директорій, git-репозиторіїв,
|
||||
npm-пакетів і шляху реєстру ClawHub.
|
||||
- npm-залежності Plugin встановлюються в керований корінь npm, скануються перед
|
||||
довірою та видаляються через npm під час uninstall, щоб підняті залежності не
|
||||
залишалися.
|
||||
- Оновлення Plugin стабільне, коли нічого не змінилося: записи встановлення,
|
||||
розв’язане джерело та ввімкнений стан залишаються неушкодженими.
|
||||
|
||||
## Локальне підтвердження під час розробки
|
||||
|
||||
Почніть вузько:
|
||||
Починайте вузько:
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes --json
|
||||
@ -53,29 +54,31 @@ pnpm check:changed
|
||||
pnpm test:changed
|
||||
```
|
||||
|
||||
Для змін у встановленні, видаленні, залежностях плагінів або package inventory також
|
||||
запускайте сфокусовані тести, що покривають відредаговану межу:
|
||||
Для змін у встановленні, видаленні, залежностях Plugin або package-inventory
|
||||
також запускайте сфокусовані тести, що покривають відредагований seam:
|
||||
|
||||
```bash
|
||||
pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
|
||||
```
|
||||
|
||||
Перед тим як будь-який Docker lane пакета використає tarball, підтвердьте артефакт пакета:
|
||||
Перш ніж будь-яка package Docker lane споживатиме tarball, доведіть артефакт
|
||||
пакета:
|
||||
|
||||
```bash
|
||||
pnpm release:check
|
||||
```
|
||||
|
||||
`release:check` запускає перевірки drift для config/docs/API, записує package dist
|
||||
inventory, виконує `npm pack --dry-run`, відхиляє заборонені packed files, встановлює
|
||||
tarball у тимчасовий prefix, запускає postinstall і виконує smoke-перевірки bundled
|
||||
channel entrypoints.
|
||||
`release:check` запускає перевірки drift для config/docs/API, записує package
|
||||
dist inventory, запускає `npm pack --dry-run`, відхиляє заборонені запаковані
|
||||
файли, встановлює tarball у тимчасовий prefix, запускає postinstall і перевіряє
|
||||
smoke для bundled channel entrypoints.
|
||||
|
||||
## Docker lanes
|
||||
|
||||
Docker lanes є product-level підтвердженням. Вони встановлюють або оновлюють реальний
|
||||
пакет усередині Linux-контейнерів і перевіряють поведінку через CLI-команди,
|
||||
startup Gateway, HTTP probes, RPC status і стан файлової системи.
|
||||
Docker lanes є підтвердженням продуктового рівня. Вони встановлюють або
|
||||
оновлюють реальний пакет усередині Linux-контейнерів і перевіряють поведінку
|
||||
через CLI-команди, startup Gateway, HTTP-проби, RPC-статус і стан файлової
|
||||
системи.
|
||||
|
||||
Під час ітерацій використовуйте сфокусовані lanes:
|
||||
|
||||
@ -84,24 +87,35 @@ pnpm test:docker:plugins
|
||||
pnpm test:docker:plugin-update
|
||||
pnpm test:docker:upgrade-survivor
|
||||
pnpm test:docker:published-upgrade-survivor
|
||||
pnpm test:docker:update-migration
|
||||
```
|
||||
|
||||
Важливі lanes:
|
||||
|
||||
- `test:docker:plugins` перевіряє smoke встановлення плагінів, встановлення з
|
||||
локальних папок, локальні папки з попередньо встановленими залежностями, git-встановлення
|
||||
із package dependencies, встановлення залежностей npm-пакетів, встановлення з
|
||||
локального ClawHub fixture, поведінку marketplace update і Claude-bundle enable/inspect.
|
||||
Встановіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub лишався hermetic/offline.
|
||||
- `test:docker:plugin-update` перевіряє, що незмінений встановлений плагін не
|
||||
перевстановлюється й не втрачає install metadata під час `openclaw plugins update`.
|
||||
- `test:docker:upgrade-survivor` встановлює tarball-кандидат поверх брудного
|
||||
old-user fixture, запускає package update плюс non-interactive doctor, потім
|
||||
запускає loopback Gateway і перевіряє збереження стану.
|
||||
- `test:docker:published-upgrade-survivor` спершу встановлює опублікований baseline,
|
||||
конфігурує його через вбудований recipe `openclaw config set`, оновлює його до
|
||||
tarball-кандидата, запускає doctor, перевіряє legacy cleanup, запускає Gateway
|
||||
і перевіряє `/healthz`, `/readyz` та RPC status.
|
||||
- `test:docker:plugins` валідує smoke встановлення Plugin, встановлення з
|
||||
локальних папок, локальні папки з попередньо встановленими залежностями,
|
||||
git-встановлення із залежностями пакета, встановлення залежностей npm-пакета,
|
||||
встановлення з локальної ClawHub fixture, поведінку marketplace update, а
|
||||
також enable/inspect для Claude-bundle. Установіть
|
||||
`OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub залишався
|
||||
герметичним/offline.
|
||||
- `test:docker:plugin-update` перевіряє, що незмінений встановлений Plugin не
|
||||
перевстановлюється й не втрачає метадані встановлення під час
|
||||
`openclaw plugins update`.
|
||||
- `test:docker:upgrade-survivor` встановлює кандидатний tarball поверх брудної
|
||||
old-user fixture, запускає оновлення пакета плюс non-interactive doctor,
|
||||
потім запускає loopback Gateway і перевіряє збереження стану.
|
||||
- `test:docker:published-upgrade-survivor` спочатку встановлює опублікований
|
||||
baseline, конфігурує його через baked рецепт `openclaw config set`, оновлює
|
||||
його до кандидатного tarball, запускає doctor, перевіряє очищення
|
||||
успадкованого стану, запускає Gateway і пробує `/healthz`, `/readyz` та
|
||||
RPC-статус.
|
||||
- `test:docker:update-migration` є cleanup-heavy lane для published-update. Вона
|
||||
стартує з налаштованого користувацького стану в стилі Discord/Telegram,
|
||||
запускає baseline doctor, щоб налаштовані залежності Plugin мали шанс
|
||||
матеріалізуватися, засіває уламки успадкованих залежностей Plugin для
|
||||
налаштованого packaged Plugin, оновлює до кандидатного tarball і вимагає, щоб
|
||||
post-update doctor видалив legacy dependency roots.
|
||||
|
||||
Корисні варіанти published-upgrade survivor:
|
||||
|
||||
@ -116,27 +130,43 @@ pnpm test:docker:published-upgrade-survivor
|
||||
```
|
||||
|
||||
Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`,
|
||||
`tilde-log-path` і `versioned-runtime-deps`. В aggregate runs
|
||||
`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі сценарії,
|
||||
сформовані за повідомленими issue.
|
||||
`plugin-deps-cleanup`, `tilde-log-path` і `versioned-runtime-deps`. В aggregate runs
|
||||
`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі
|
||||
сценарії, сформовані за reported issues.
|
||||
|
||||
Повна update migration навмисно відокремлена від Full Release CI. Використовуйте
|
||||
ручний workflow `Update Migration`, коли release-питання звучить так: "чи може
|
||||
кожен опублікований stable release від 2026.4.23 і далі оновитися до цього
|
||||
кандидата та очистити уламки залежностей Plugin?":
|
||||
|
||||
```bash
|
||||
gh workflow run update-migration.yml \
|
||||
--ref main \
|
||||
-f workflow_ref=main \
|
||||
-f package_ref=main \
|
||||
-f baselines=all-since-2026.4.23 \
|
||||
-f scenarios=plugin-deps-cleanup
|
||||
```
|
||||
|
||||
## Package Acceptance
|
||||
|
||||
Package Acceptance — це GitHub-native пакетний gate. Він resolves один пакет-кандидат
|
||||
у tarball `package-under-test`, записує версію та SHA-256, а потім запускає reusable
|
||||
Docker E2E lanes проти саме цього tarball. Workflow harness ref відокремлений від
|
||||
package source ref, тому поточна тестова логіка може перевіряти старіші довірені релізи.
|
||||
Package Acceptance є GitHub-native package gate. Він розв’язує один кандидатний
|
||||
пакет у tarball `package-under-test`, записує версію та SHA-256, потім запускає
|
||||
reusable Docker E2E lanes проти саме цього tarball. Workflow harness ref
|
||||
відокремлений від package source ref, тому поточна тестова логіка може
|
||||
валідувати старіші trusted releases.
|
||||
|
||||
Джерела кандидата:
|
||||
|
||||
- `source=npm`: перевірити `openclaw@beta`, `openclaw@latest` або точну
|
||||
- `source=npm`: валідувати `openclaw@beta`, `openclaw@latest` або точну
|
||||
опубліковану версію.
|
||||
- `source=ref`: запакувати довірену гілку, тег або commit з вибраним поточним
|
||||
- `source=ref`: запакувати trusted branch, tag або commit із вибраним поточним
|
||||
harness.
|
||||
- `source=url`: перевірити HTTPS tarball з обов’язковим `package_sha256`.
|
||||
- `source=artifact`: повторно використати tarball, завантажений іншим Actions run.
|
||||
- `source=url`: валідувати HTTPS tarball з обов’язковим `package_sha256`.
|
||||
- `source=artifact`: повторно використати tarball, завантажений іншим Actions
|
||||
run.
|
||||
|
||||
Release checks викликають Package Acceptance з набором package/update/plugin:
|
||||
Release checks викликають Package Acceptance з package/update/plugin set:
|
||||
|
||||
```text
|
||||
doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update
|
||||
@ -150,11 +180,16 @@ published_upgrade_survivor_scenarios=reported-issues
|
||||
telegram_mode=mock-openai
|
||||
```
|
||||
|
||||
Це тримає міграцію пакета, перемикання update channel, очищення застарілих
|
||||
залежностей плагінів, offline-покриття плагінів, поведінку plugin update і Telegram
|
||||
package QA на одному resolved artifact.
|
||||
Це тримає package migration, перемикання каналу оновлень, очищення застарілих
|
||||
залежностей Plugin, offline-покриття Plugin, поведінку оновлення Plugin і
|
||||
Telegram package QA на одному розв’язаному артефакті.
|
||||
|
||||
Запустіть package profile вручну під час перевірки кандидата перед релізом:
|
||||
`release-history` є обмеженим release-check sample: останні шість stable
|
||||
releases, `2026.4.23` і один старіший pre-date anchor. Для вичерпного покриття
|
||||
published update migration використовуйте `all-since-2026.4.23` в окремому
|
||||
workflow Update Migration замість Full Release CI.
|
||||
|
||||
Запустіть package profile вручну під час валідації кандидата перед release:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -168,68 +203,69 @@ gh workflow run package-acceptance.yml \
|
||||
-f telegram_mode=mock-openai
|
||||
```
|
||||
|
||||
Використовуйте `suite_profile=product`, коли release question включає MCP channels,
|
||||
cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте
|
||||
`suite_profile=full` лише тоді, коли потрібне повне Docker-покриття release-path.
|
||||
Використовуйте `suite_profile=product`, коли release-питання включає MCP
|
||||
channels, cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте
|
||||
`suite_profile=full` лише тоді, коли потрібне повне покриття Docker release-path.
|
||||
|
||||
## Релізний стандарт
|
||||
## Типовий release
|
||||
|
||||
Для release candidates стандартний proof stack такий:
|
||||
Для release candidates типовий стек підтвердження такий:
|
||||
|
||||
1. `pnpm check:changed` і `pnpm test:changed` для source-level regressions.
|
||||
2. `pnpm release:check` для цілісності package artifact.
|
||||
3. Package Acceptance `package` profile або release-check custom package
|
||||
1. `pnpm check:changed` і `pnpm test:changed` для source-level регресій.
|
||||
2. `pnpm release:check` для цілісності артефакту пакета.
|
||||
3. Package Acceptance profile `package` або release-check custom package
|
||||
lanes для контрактів install/update/plugin.
|
||||
4. Cross-OS release checks для OS-specific installer, onboarding і platform
|
||||
behavior.
|
||||
5. Live suites лише тоді, коли змінена поверхня зачіпає provider або hosted-service
|
||||
behavior.
|
||||
5. Live-набори лише тоді, коли змінена поверхня торкається поведінки провайдера
|
||||
або hosted-service.
|
||||
|
||||
На машинах maintainer широкі gates і Docker/package product proof мають запускатися
|
||||
в Testbox, якщо явно не виконується local proof.
|
||||
На машинах мейнтейнерів broad gates і Docker/package product proof мають
|
||||
запускатися в Testbox, якщо явно не виконується локальне підтвердження.
|
||||
|
||||
## Legacy-сумісність
|
||||
## Успадкована сумісність
|
||||
|
||||
Compatibility leniency вузька й обмежена в часі:
|
||||
Поблажливість сумісності вузька й обмежена в часі:
|
||||
|
||||
- Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть tolerate
|
||||
already-shipped package metadata gaps у Package Acceptance.
|
||||
- Опублікований пакет `2026.4.26` може warn щодо local build metadata stamp
|
||||
files, які вже були shipped.
|
||||
- Пізніші пакети мають задовольняти modern contracts. Ті самі gaps fail замість
|
||||
warning або skipping.
|
||||
- Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть терпіти
|
||||
вже shipped gaps у package metadata в Package Acceptance.
|
||||
- Опублікований пакет `2026.4.26` може попереджати про local build metadata
|
||||
stamp files, які вже shipped.
|
||||
- Пізніші пакети мають задовольняти сучасні контракти. Ті самі gaps мають
|
||||
падати замість warning або skipping.
|
||||
|
||||
Не додавайте нові startup migrations для цих старих форм. Додайте або розширте
|
||||
doctor repair, а потім підтвердьте це за допомогою `upgrade-survivor` або
|
||||
doctor repair, потім доведіть це за допомогою `upgrade-survivor` або
|
||||
`published-upgrade-survivor`.
|
||||
|
||||
## Додавання покриття
|
||||
|
||||
Коли змінюєте поведінку оновлення або плагінів, додавайте покриття на найнижчому
|
||||
шарі, який може впасти з правильної причини:
|
||||
Коли змінюєте поведінку update або Plugin, додавайте покриття на найнижчому
|
||||
рівні, який може впасти з правильної причини:
|
||||
|
||||
- Чиста path або metadata logic: unit test поруч із source.
|
||||
- Package inventory або packed-file behavior: `package-dist-inventory` або tarball
|
||||
checker test.
|
||||
- Чиста path або metadata logic: unit test поруч із джерелом.
|
||||
- Поведінка package inventory або packed-file: `package-dist-inventory` або
|
||||
tarball checker test.
|
||||
- CLI install/update behavior: Docker lane assertion або fixture.
|
||||
- Published-release migration behavior: scenario `published-upgrade-survivor`.
|
||||
- Registry/package source behavior: fixture `test:docker:plugins` або ClawHub
|
||||
fixture server.
|
||||
- Поведінка published-release migration: сценарій `published-upgrade-survivor`.
|
||||
- Поведінка registry/package source: fixture `test:docker:plugins` або сервер
|
||||
ClawHub fixture.
|
||||
|
||||
Тримайте нові Docker fixtures hermetic за замовчуванням. Використовуйте local fixture
|
||||
registries і fake packages, якщо метою тесту не є live registry behavior.
|
||||
Нові Docker fixtures за замовчуванням мають бути герметичними. Використовуйте
|
||||
локальні fixture registries і fake packages, якщо метою тесту не є live registry
|
||||
behavior.
|
||||
|
||||
## Тріаж збоїв
|
||||
|
||||
Почніть з ідентичності артефакта:
|
||||
Починайте з ідентичності артефакту:
|
||||
|
||||
- Package Acceptance `resolve_package` summary: source, version, SHA-256 і
|
||||
- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і
|
||||
artifact name.
|
||||
- Docker artifacts: `.artifacts/docker-tests/**/summary.json`,
|
||||
`failures.json`, lane logs і rerun commands.
|
||||
- Upgrade survivor summary: `.artifacts/upgrade-survivor/summary.json`,
|
||||
- Summary upgrade survivor: `.artifacts/upgrade-survivor/summary.json`,
|
||||
включно з baseline version, candidate version, scenario, phase timings і
|
||||
recipe steps.
|
||||
|
||||
Надавайте перевагу повторному запуску exact lane, що впав, з тим самим package
|
||||
artifact, а не повторному запуску всього release umbrella.
|
||||
Віддавайте перевагу повторному запуску саме failed exact lane з тим самим
|
||||
package artifact, а не повторному запуску всієї release umbrella.
|
||||
|
||||
@ -1,64 +1,64 @@
|
||||
---
|
||||
read_when:
|
||||
- Пошук визначень публічних каналів релізів
|
||||
- Запуск валідації релізу або приймання пакета
|
||||
- Шукаєте правила найменування версій і ритм випусків
|
||||
summary: Канали релізу, контрольний список оператора, середовища перевірки, іменування версій і періодичність
|
||||
- Пошук визначень публічних каналів випуску
|
||||
- Запуск перевірки випуску або приймання пакета
|
||||
- Шукаєте правила іменування версій і ритм випусків
|
||||
summary: Канали випуску, контрольний список оператора, середовища перевірки, найменування версій і періодичність
|
||||
title: Політика випусків
|
||||
x-i18n:
|
||||
generated_at: "2026-05-01T23:10:04Z"
|
||||
generated_at: "2026-05-01T23:38:40Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 89274e9cbd5546b718517053e37574ceae53d4031d6ec02a033d250908e93bfd
|
||||
source_hash: e915840070324f7614c993d20490f0bf4c9b266c57ce74eddfc461e019d3dc07
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw має три публічні канали випусків:
|
||||
|
||||
- стабільний: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
|
||||
- бета: передрелізні теги, які публікуються в npm `beta`
|
||||
- стабільний: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
|
||||
- бета: передвипускні теги, які публікуються в npm `beta`
|
||||
- розробницький: рухома вершина `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-випуск
|
||||
- `beta` означає поточну ціль бета-встановлення
|
||||
- Стабільні та стабільні корекційні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або просунути перевірену бета-збірку пізніше
|
||||
- `beta` означає поточну ціль встановлення бета-версії
|
||||
- Стабільні та стабільні коригувальні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або просунути перевірену бета-збірку пізніше
|
||||
- Кожен стабільний випуск OpenClaw постачає npm-пакет і застосунок macOS разом;
|
||||
бета-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а
|
||||
збирання/підпис/нотаризація застосунку Mac зарезервовані для стабільних випусків, якщо це явно не запитано
|
||||
бета-випуски зазвичай спершу перевіряють і публікують шлях npm/package, а
|
||||
збирання/підпис/нотаризацію застосунку mac залишають для стабільних випусків, якщо це явно не запитано
|
||||
|
||||
## Частота випусків
|
||||
## Періодичність випусків
|
||||
|
||||
- Випуски рухаються спершу через бета-канал
|
||||
- Стабільний випуск іде лише після перевірки останньої бети
|
||||
- Стабільний випуск іде лише після перевірки останньої бета-версії
|
||||
- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
|
||||
з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
|
||||
розробку в `main`
|
||||
- Якщо бета-тег уже було надіслано або опубліковано й він потребує виправлення, супровідники створюють
|
||||
- Якщо бета-тег уже надіслано або опубліковано й він потребує виправлення, супровідники створюють
|
||||
наступний тег `-beta.N` замість видалення або повторного створення старого бета-тега
|
||||
- Детальна процедура випуску, затвердження, облікові дані та примітки з відновлення
|
||||
- Детальна процедура випуску, погодження, облікові дані та нотатки з відновлення
|
||||
доступні лише супровідникам
|
||||
|
||||
## Контрольний список оператора випуску
|
||||
|
||||
Цей контрольний список показує публічну форму процесу випуску. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в
|
||||
інструкції випуску лише для супровідників.
|
||||
підписування, нотаризація, відновлення dist-tag і деталі аварійного відкотування залишаються в
|
||||
посібнику з випуску лише для супровідників.
|
||||
|
||||
1. Почніть із поточного `main`: завантажте останні зміни, підтвердьте, що цільовий коміт надіслано,
|
||||
і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку.
|
||||
2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
|
||||
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте це, надішліть і ще раз виконайте rebase/pull
|
||||
перед створенням гілки.
|
||||
1. Почніть із поточного `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано,
|
||||
і підтвердьте, що поточний CI `main` достатньо зелений, щоб створювати від нього гілку.
|
||||
2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою
|
||||
`/changelog`, зберігайте записи орієнтованими на користувача, закомітьте його, надішліть його та виконайте rebase/pull
|
||||
ще раз перед створенням гілки.
|
||||
3. Перегляньте записи сумісності випуску в
|
||||
`src/plugins/compat/registry.ts` і
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
|
||||
@ -66,181 +66,183 @@ OpenClaw має три публічні канали випусків:
|
||||
навмисно збережено.
|
||||
4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском
|
||||
безпосередньо в `main`.
|
||||
5. Підніміть версію в усіх потрібних місцях для запланованого тега, а потім запустіть
|
||||
5. Підвищте версію в кожному потрібному місці для запланованого тега, потім запустіть
|
||||
локальну детерміновану попередню перевірку:
|
||||
`pnpm check:test-types`, `pnpm check:architecture`,
|
||||
`pnpm build && pnpm ui:build` і `pnpm release:check`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
|
||||
для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA гілки випуску.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До створення тега
|
||||
для перевіркової попередньої перевірки дозволено повний 40-символьний SHA гілки випуску.
|
||||
Збережіть успішний `preflight_run_id`.
|
||||
7. Запустіть усі передрелізні тести за допомогою `Full Release Validation` для
|
||||
7. Запустіть усі передрелізні тести через `Full Release Validation` для
|
||||
гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо перевірка не проходить, виправте в гілці випуску та повторно запустіть найменший невдалий
|
||||
файл, канал, завдання workflow, профіль пакета, провайдера або список дозволених моделей, який
|
||||
доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить
|
||||
для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо перевірка не пройшла, виправте в гілці випуску та повторно запустіть найменший невдалий
|
||||
файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що
|
||||
доводить виправлення. Повторно запускайте повну парасолькову перевірку лише тоді, коли змінена поверхня робить
|
||||
попередні докази застарілими.
|
||||
9. Для бети позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, а потім запустіть
|
||||
post-publish приймання пакета проти опублікованого пакета `openclaw@YYYY.M.D-beta.N`
|
||||
або `openclaw@beta`. Якщо надіслана або опублікована бета потребує виправлення, створіть
|
||||
наступний `-beta.N`; не видаляйте й не переписуйте стару бету.
|
||||
10. Для стабільного випуску продовжуйте лише після того, як перевірена бета або реліз-кандидат матиме
|
||||
потрібні докази перевірки. Стабільна публікація npm повторно використовує успішний
|
||||
9. Для бета-версії поставте тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть
|
||||
приймальну перевірку пакета після публікації для опублікованого пакета `openclaw@YYYY.M.D-beta.N`
|
||||
або `openclaw@beta`. Якщо надіслана або опублікована бета-версія потребує виправлення, створіть
|
||||
наступний `-beta.N`; не видаляйте й не переписуйте стару бета-версію.
|
||||
10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат випуску матиме
|
||||
потрібні докази перевірки. Публікація стабільного npm повторно використовує успішний
|
||||
артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного випуску macOS
|
||||
також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
|
||||
`appcast.xml` у `main`.
|
||||
11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний
|
||||
опублікований-npm Telegram E2E, коли потрібен доказ каналу після публікації,
|
||||
просування dist-tag за потреби, примітки GitHub release/prerelease з
|
||||
11. Після публікації запустіть верифікатор npm після публікації, необов’язковий самостійний
|
||||
E2E Telegram для опублікованого npm, коли потрібен доказ каналу після публікації,
|
||||
просування dist-tag за потреби, нотатки GitHub release/prerelease з
|
||||
повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
|
||||
|
||||
## Попередня перевірка випуску
|
||||
|
||||
- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
|
||||
покритим поза швидшим локальним шлюзом `pnpm check`
|
||||
- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпортів
|
||||
і архітектурних меж були зеленими поза швидшим локальним шлюзом
|
||||
- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
|
||||
імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
|
||||
- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
|
||||
релізні артефакти `dist/*` і пакет Control UI існували для кроку перевірки
|
||||
релізні артефакти `dist/*` і пакет Control UI існували для кроку валідації
|
||||
пакування
|
||||
- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
|
||||
запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, запускає ручний `CI` і запускає
|
||||
`OpenClaw Release Checks` для install smoke, package acceptance, Docker
|
||||
release-path наборів, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
|
||||
lanes. З `release_profile=full` і `rerun_group=all` він також запускає package
|
||||
Telegram E2E для артефакта `release-package-under-test` з release
|
||||
checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий
|
||||
Telegram E2E також має перевірити опублікований npm-пакет. Надайте
|
||||
`evidence_package_spec`, коли приватний evidence report має підтвердити, що
|
||||
`OpenClaw Release Checks` для перевірки встановлення, приймання пакета, наборів
|
||||
релізного шляху Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
|
||||
lanes. З `release_profile=full` і `rerun_group=all` він також запускає пакетний
|
||||
Telegram E2E для артефакту `release-package-under-test` з релізних перевірок.
|
||||
Надайте `npm_telegram_package_spec` після публікації, коли той самий Telegram E2E
|
||||
також має підтвердити опублікований npm-пакет. Надайте
|
||||
`evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
|
||||
валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
|
||||
Приклад:
|
||||
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
|
||||
- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ
|
||||
- Запустіть ручний workflow `Package Acceptance`, коли потрібен побічний доказ
|
||||
для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
|
||||
`openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`,
|
||||
`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 для цього
|
||||
Actions. Workflow розв’язує кандидата до
|
||||
`package-under-test`, повторно використовує релізний планувальник Docker E2E для цього
|
||||
tarball і може запускати Telegram QA для того самого tarball з
|
||||
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані
|
||||
Docker lanes включають `published-upgrade-survivor`, артефакт пакета є кандидатом, а `published_upgrade_survivor_baseline` вибирає
|
||||
опублікований baseline.
|
||||
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли
|
||||
вибрані Docker lanes містять `published-upgrade-survivor`, артефакт пакета
|
||||
є кандидатом, а `published_upgrade_survivor_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`: lanes для install/channel/agent, gateway network і config reload
|
||||
- `package`: lanes для artifact-native package/update/plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль package плюс MCP-канали, очищення cron/субагентів,
|
||||
OpenAI web search і OpenWebUI
|
||||
- `full`: Docker release-path chunks з OpenWebUI
|
||||
- `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
|
||||
- `package`: нативні для артефакту lanes пакета/оновлення/Plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль пакета плюс канали MCP, очищення cron/subagent,
|
||||
вебпошук OpenAI і OpenWebUI
|
||||
- `full`: фрагменти релізного шляху Docker з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
|
||||
- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
|
||||
покриття для релізного кандидата. Ручні запуски CI обходять changed
|
||||
scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
|
||||
contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
|
||||
docs checks, Python skills, Windows, macOS, Android і Control UI i18n
|
||||
- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
|
||||
для кандидата релізу. Ручні запуски CI обходять changed scoping і примусово запускають
|
||||
Linux Node shards, bundled-plugin shards, контракти каналів,
|
||||
сумісність Node 22, `check`, `check-additional`, перевірку збірки,
|
||||
перевірки документації, 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-приймач і перевіряє експортовані назви trace
|
||||
- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він перевіряє
|
||||
QA-lab через локальний приймач OTLP/HTTP і перевіряє експортовані назви trace
|
||||
span, обмежені атрибути та редагування вмісту/ідентифікаторів без
|
||||
потреби в Opik, Langfuse або іншому зовнішньому колекторі.
|
||||
- Запускайте `pnpm release:check` перед кожним тегованим релізом
|
||||
- Релізні перевірки тепер запускаються в окремому ручному workflow:
|
||||
потреби в Opik, Langfuse або іншому зовнішньому collector.
|
||||
- Запускайте `pnpm release:check` перед кожним релізом із тегом
|
||||
- Релізні перевірки тепер виконуються в окремому ручному workflow:
|
||||
`OpenClaw Release Checks`
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий
|
||||
live Matrix profile і Telegram QA lane перед схваленням релізу. Live
|
||||
lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібна повна інвентаризація Matrix
|
||||
- `OpenClaw Release Checks` також запускає mock parity gate QA Lab плюс швидкий
|
||||
live-профіль Matrix і lane Telegram QA перед схваленням релізу. Live
|
||||
lanes використовують середовище `qa-live-shared`; Telegram також використовує leases
|
||||
облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
|
||||
transport, media та E2EE паралельно.
|
||||
- Cross-OS install і upgrade runtime validation є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
|
||||
- Крос-ОС валідація встановлення й оновлення runtime є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які викликають
|
||||
reusable workflow
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
|
||||
- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким,
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму
|
||||
- Це розділення навмисне: тримати реальний шлях npm-релізу коротким,
|
||||
детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у власній
|
||||
lane, щоб не затримувати й не блокувати публікацію
|
||||
- Релізні перевірки із секретами слід запускати через `Full Release
|
||||
lane, щоб вони не затримували й не блокували публікацію
|
||||
- Релізні перевірки з секретами слід запускати через `Full Release
|
||||
Validation` або з workflow ref `main`/release, щоб логіка workflow і
|
||||
секрети залишалися контрольованими
|
||||
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
|
||||
резолвлений коміт доступний з гілки OpenClaw або релізного тегу
|
||||
розв’язаний коміт досяжний з гілки OpenClaw або релізного тегу
|
||||
- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
|
||||
повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
|
||||
- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для
|
||||
перевірки метаданих пакета; реальна публікація все одно вимагає справжнього релізного тегу
|
||||
- Обидва workflows тримають реальний шлях публікації та promotion на GitHub-hosted
|
||||
runners, тоді як немутаційний шлях валідації може використовувати більші
|
||||
повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тегу
|
||||
- Цей шлях SHA є лише валідаційним і не може бути підвищений до реальної публікації
|
||||
- У режимі 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
|
||||
- npm release preflight більше не чекає на окрему lane релізних перевірок
|
||||
- Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(або відповідний beta/correction тег) перед схваленням
|
||||
- Після npm publish запустіть
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(або відповідну 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-пакета з використанням спільного пулу орендованих облікових даних Telegram.
|
||||
Локальні одноразові запуски maintainers можуть опускати змінні Convex і передавати три
|
||||
env-облікові дані `OPENCLAW_QA_TELEGRAM_*` напряму.
|
||||
для опублікованого npm-пакета з використанням спільного пулу leased облікових даних Telegram.
|
||||
Локальні одноразові запуски maintainers можуть опускати Convex vars і передавати три
|
||||
env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
|
||||
- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через
|
||||
ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
|
||||
не запускається під час кожного merge.
|
||||
не запускається на кожному merge.
|
||||
- Автоматизація релізів maintainer тепер використовує preflight-then-promote:
|
||||
- реальний npm publish має пройти успішний npm `preflight_run_id`
|
||||
- реальний npm publish має бути запущений з тієї самої гілки `main` або
|
||||
`release/YYYY.M.D`, що й успішний preflight run
|
||||
- стабільні npm-релізи за замовчуванням спрямовуються на `beta`
|
||||
- стабільний npm publish може явно націлюватися на `latest` через workflow input
|
||||
- мутація npm dist-tag на основі токена тепер живе в
|
||||
- мутація npm dist-tag на основі токена тепер розміщена в
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
з міркувань безпеки, бо `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як
|
||||
для безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
|
||||
публічний репозиторій зберігає OIDC-only publish
|
||||
- публічний `macOS Release` призначений лише для валідації; коли тег існує лише в
|
||||
release branch, але workflow запускається з `main`, встановіть
|
||||
- публічний `macOS Release` є лише валідаційним; коли тег існує лише на
|
||||
релізній гілці, але workflow запускається з `main`, встановіть
|
||||
`public_release_branch=release/YYYY.M.D`
|
||||
- реальний приватний mac publish має пройти успішні приватні mac
|
||||
`preflight_run_id` і `validate_run_id`
|
||||
- реальні шляхи публікації просувають підготовлені артефакти замість того, щоб
|
||||
перебудовувати їх знову
|
||||
- реальні шляхи publish просувають підготовлені артефакти замість того, щоб збирати
|
||||
їх знову
|
||||
- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier
|
||||
також перевіряє той самий шлях оновлення з тимчасовим prefix з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
також перевіряє той самий шлях оновлення temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
|
||||
базовому stable payload
|
||||
базовому стабільному payload
|
||||
- npm release preflight fails closed, якщо tarball не містить одночасно
|
||||
`dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
|
||||
щоб ми знову не відправили порожню browser dashboard
|
||||
- Post-publish verification також перевіряє, що опубліковані plugin entrypoints і
|
||||
метадані пакета присутні у встановленому registry layout. Реліз, який
|
||||
постачає відсутні plugin runtime payloads, провалює postpublish verifier і
|
||||
не може бути просунутий до `latest`.
|
||||
- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до
|
||||
candidate update tarball, тож installer e2e ловить випадкове роздування pack
|
||||
щоб ми знову не поставили порожній браузерний dashboard
|
||||
- Post-publish verification також перевіряє, що опубліковані entrypoints Plugin і
|
||||
метадані пакета присутні в установленому registry layout. Реліз, який
|
||||
постачає відсутні runtime payloads Plugin, провалює postpublish verifier і
|
||||
не може бути promoted до `latest`.
|
||||
- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для
|
||||
candidate update tarball, тож installer e2e ловить випадкове роздуття пакета
|
||||
до шляху release publish
|
||||
- Якщо релізна робота торкалася планування CI, manifests таймінгів extension або
|
||||
матриць тестів extension, регенеруйте й перегляньте outputs матриці
|
||||
`plugin-prerelease-extension-shard`, якими володіє planner, з
|
||||
- Якщо релізна робота торкалася планування CI, extension timing manifests або
|
||||
extension test matrices, повторно згенеруйте й перегляньте planner-owned
|
||||
matrix outputs `plugin-prerelease-extension-shard` з
|
||||
`.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
|
||||
описували застарілий CI layout
|
||||
- Готовність stable macOS release також включає 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
|
||||
для цієї релізної версії
|
||||
- Готовність стабільного релізу macOS також включає поверхні оновлювача:
|
||||
- GitHub release має врешті містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `appcast.xml` на `main` має вказувати на новий стабільний zip після publish
|
||||
- запакований app має зберігати non-debug bundle id, непорожню Sparkle feed
|
||||
URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
|
||||
для цієї версії релізу
|
||||
|
||||
## Релізні тестові бокси
|
||||
|
||||
`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з
|
||||
однієї точки входу. Запустіть його з довіреного workflow ref `main` і передайте release
|
||||
branch, tag або full commit SHA як `ref`:
|
||||
однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну
|
||||
гілку, тег або повний SHA коміту як `ref`:
|
||||
|
||||
```bash
|
||||
gh workflow run full-release-validation.yml \
|
||||
@ -252,35 +254,34 @@ gh workflow run full-release-validation.yml \
|
||||
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
|
||||
```
|
||||
|
||||
Workflow резолвить target ref, запускає ручний `CI` з
|
||||
Workflow розв’язує target ref, запускає ручний `CI` з
|
||||
`target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і запускає
|
||||
standalone 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. Повний запуск прийнятний лише тоді, коли
|
||||
окремий пакетний Telegram E2E, коли `release_profile=full` з
|
||||
`rerun_group=all` або коли задано `npm_telegram_package_spec`. `OpenClaw Release
|
||||
Checks` далі розгалужується на перевірку встановлення, cross-OS release checks, live/E2E Docker
|
||||
release-path coverage, Package Acceptance з Telegram package QA, паритет QA Lab,
|
||||
live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
|
||||
summary `Full Release Validation`
|
||||
показує `normal_ci` і `release_checks` як успішні. У режимі full/all
|
||||
дочірній `npm_telegram` також має бути успішним; поза full/all його пропущено,
|
||||
дочірній `npm_telegram` також має бути успішним; поза full/all його пропускають,
|
||||
якщо не було надано опублікований `npm_telegram_package_spec`. Фінальний
|
||||
verifier summary містить таблиці найповільніших jobs для кожного дочірнього run, щоб release
|
||||
manager міг бачити поточний критичний шлях без завантаження logs.
|
||||
verifier summary містить таблиці slowest-job для кожного дочірнього запуску, тож release
|
||||
manager може бачити поточний critical path без завантаження логів.
|
||||
Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
|
||||
повної stage matrix, точних назв workflow jobs, відмінностей stable versus full profile,
|
||||
artifacts і handles для focused rerun.
|
||||
Дочірні workflows запускаються з довіреного ref, який запускає `Full Release
|
||||
повної матриці етапів, точних назв job workflow, відмінностей між stable і full profile,
|
||||
артефактів і ручок для сфокусованого повторного запуску.
|
||||
Дочірні workflow запускаються з довіреного ref, який запускає `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на
|
||||
старішу release branch або tag. Окремого input workflow-ref для Full Release Validation
|
||||
немає; вибирайте довірений harness, вибираючи ref workflow run.
|
||||
старішу релізну гілку або тег. Окремого input workflow-ref для Full Release Validation
|
||||
немає; вибирайте довірений harness, вибираючи ref запуску workflow.
|
||||
|
||||
Використовуйте `release_profile`, щоб вибрати ширину live/provider:
|
||||
|
||||
- `minimum`: найшвидший release-critical OpenAI/core live і Docker path
|
||||
- `stable`: minimum плюс stable provider/backend coverage для release approval
|
||||
- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
|
||||
- `full`: stable плюс broad advisory provider/media coverage
|
||||
|
||||
`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз визначити цільове посилання як `release-package-under-test`, і повторно використовує цей artifact як у Docker-перевірках release-path, так і в Package Acceptance. Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок package.
|
||||
Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено змінну repo/org, інакше `openai/gpt-5.5`, оскільки ця lane перевіряє package install, onboarding, Gateway startup і один live agent turn, а не benchmark найповільнішої моделі за замовчуванням. Ширша матриця live provider лишається місцем для model-specific coverage.
|
||||
`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати цільове посилання як `release-package-under-test`, і повторно використовує цей артефакт як у Docker-перевірках release-path, так і в Package Acceptance. Це утримує всі package-facing бокси на тих самих байтах і уникає повторних збірок пакета. Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли змінну repo/org задано, інакше `openai/gpt-5.5`, бо ця лінія доводить установлення пакета, onboarding, запуск Gateway і один live agent turn, а не бенчмарк найповільнішої стандартної моделі. Ширша матриця live provider залишається місцем для покриття, специфічного для моделей.
|
||||
|
||||
Використовуйте ці варіанти залежно від етапу релізу:
|
||||
|
||||
@ -312,22 +313,22 @@ gh workflow run full-release-validation.yml \
|
||||
-f npm_telegram_provider_mode=mock-openai
|
||||
```
|
||||
|
||||
Не використовуйте повний umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box завершується з помилкою, використовуйте failed child workflow, job, Docker lane, package profile, model provider або QA lane для наступного доказу. Запускайте повний umbrella знову лише тоді, коли виправлення змінило shared release orchestration або зробило попередні all-box evidence застарілими. Фінальний verifier umbrella повторно перевіряє записані child workflow run ids, тож після успішного повторного запуску child workflow перезапустіть лише failed parent job `Verify full validation`.
|
||||
Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один бокс падає, використайте невдалий дочірній workflow, job, Docker-лінію, профіль пакета, provider моделі або QA-лінію для наступного доказу. Запускайте повну парасольку знову лише тоді, коли виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх боксів застарілими. Фінальний верифікатор парасольки повторно перевіряє записані ids запусків дочірніх workflow, тож після успішного повторного запуску дочірнього workflow повторно запустіть лише невдалий батьківський job `Verify full validation`.
|
||||
|
||||
Для обмеженого відновлення передайте `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.
|
||||
Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це справжній запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` запускає лише release-only дочірній Plugin, `release-checks` запускає кожен релізний бокс, а вужчі релізні групи — це `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`. Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; повні/all запуски з `release_profile=full` використовують артефакт пакета release-checks.
|
||||
|
||||
### Vitest
|
||||
|
||||
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, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS, Android і Control UI i18n.
|
||||
Бокс Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно обходить changed scoping і примусово запускає звичайний граф тестів для release candidate: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS, Android і Control UI i18n.
|
||||
|
||||
Використовуйте цей box, щоб відповісти: «чи пройшло source tree повний normal test suite?» Це не те саме, що release-path product validation. Evidence, які слід зберігати:
|
||||
Використовуйте цей бокс, щоб відповісти: «чи пройшло дерево вихідного коду повний звичайний набір тестів?» Це не те саме, що product validation на release-path. Докази, які потрібно зберегти:
|
||||
|
||||
- summary `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`, коли run потребує performance analysis
|
||||
- зведення `Full Release Validation`, що показує URL відправленого запуску `CI`
|
||||
- зелений запуск `CI` на точному цільовому SHA
|
||||
- назви невдалих або повільних shard із CI jobs під час розслідування регресій
|
||||
- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли запуск потребує аналізу продуктивності
|
||||
|
||||
Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але не Docker, QA Lab, live, cross-OS або package boxes:
|
||||
Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але не Docker, QA Lab, live, cross-OS або package бокси:
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
@ -335,61 +336,61 @@ 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 Docker environments, а не лише source-level tests.
|
||||
Бокс Docker живе в `OpenClaw Release Checks` через `openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode workflow `install-smoke`. Він перевіряє release candidate через запаковані Docker-середовища, а не лише тести на рівні вихідного коду.
|
||||
|
||||
Release Docker coverage включає:
|
||||
Покриття Release Docker включає:
|
||||
|
||||
- full install smoke з увімкненим slow Bun global install smoke
|
||||
- підготовку/повторне використання root Dockerfile smoke image за target SHA, де QR, root/Gateway і installer/Bun smoke jobs запускаються як окремі install-smoke shards
|
||||
- повний install smoke із увімкненим повільним Bun global install smoke
|
||||
- підготовку/повторне використання smoke image кореневого Dockerfile за цільовим SHA, з QR, root/gateway та installer/Bun smoke jobs, що запускаються як окремі install-smoke shards
|
||||
- repository E2E lanes
|
||||
- release-path Docker chunks: `core`, `package-update-openai`,
|
||||
- Docker chunks release-path: `core`, `package-update-openai`,
|
||||
`package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`,
|
||||
`plugins-runtime-services`,
|
||||
`plugins-runtime-install-a`, `plugins-runtime-install-b`,
|
||||
`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
|
||||
- покриття OpenWebUI всередині chunk `plugins-runtime-services`, коли його запитано
|
||||
- розділені лінії встановлення/видалення bundled plugin
|
||||
`bundled-plugin-install-uninstall-0` до
|
||||
`bundled-plugin-install-uninstall-23`
|
||||
- live/E2E provider suites і Docker live model coverage, коли release checks
|
||||
включають live suites
|
||||
|
||||
Використовуйте 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 замість повторного запуску всіх release chunks. Згенеровані rerun commands містять попередній `package_artifact_run_id` і prepared Docker image inputs, коли доступні, тому failed lane може повторно використати той самий tarball і GHCR images.
|
||||
Використовуйте Docker-артефакти перед повторним запуском. Планувальник release-path завантажує `.artifacts/docker-tests/` з логами ліній, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні `package_artifact_run_id` і prepared Docker image inputs, коли доступні, тож невдала лінія може повторно використати той самий tarball і GHCR images.
|
||||
|
||||
### QA Lab
|
||||
|
||||
QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic behavior і channel-level release gate, окремий від Vitest і Docker package mechanics.
|
||||
Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це agentic behavior і channel-level release gate, окремий від Vitest і механіки Docker package.
|
||||
|
||||
Release QA Lab coverage включає:
|
||||
Покриття Release QA Lab включає:
|
||||
|
||||
- mock parity gate, що порівнює candidate lane OpenAI з baseline Opus 4.6 за допомогою agentic parity pack
|
||||
- fast live Matrix QA profile з використанням environment `qa-live-shared`
|
||||
- mock parity gate, що порівнює OpenAI candidate lane з Opus 4.6 baseline за допомогою agentic parity pack
|
||||
- швидкий live Matrix QA profile з використанням середовища `qa-live-shared`
|
||||
- live Telegram QA lane з використанням Convex CI credential leases
|
||||
- `pnpm qa:otel:smoke`, коли release telemetry потребує explicit local proof
|
||||
- `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу
|
||||
|
||||
Використовуйте цей box, щоб відповісти: «чи реліз поводиться правильно в QA scenarios і live channel flows?» Зберігайте artifact URLs для parity, Matrix і Telegram lanes під час схвалення релізу. Full Matrix coverage лишається доступним як manual sharded QA-Lab run, а не default release-critical lane.
|
||||
Використовуйте цей бокс, щоб відповісти: «чи поводиться реліз правильно у QA scenarios і live channel flows?» Зберігайте URL артефактів для parity, Matrix і Telegram lanes під час схвалення релізу. Повне покриття Matrix залишається доступним як ручний sharded QA-Lab run, а не стандартна release-critical lane.
|
||||
|
||||
### Package
|
||||
### Пакет
|
||||
|
||||
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, а також тримає workflow harness ref окремо від package source ref.
|
||||
Бокс Package — це installable-product gate. Він підтримується `Package Acceptance` і resolver `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє package inventory, записує версію пакета і SHA-256 та тримає workflow harness ref окремо від package source ref.
|
||||
|
||||
Підтримувані candidate sources:
|
||||
Підтримувані джерела candidate:
|
||||
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release version
|
||||
- `source=ref`: пакує довірені `package_ref` branch, tag або full commit SHA з вибраним harness `workflow_ref`
|
||||
- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256`
|
||||
- `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw
|
||||
- `source=ref`: pack довірену `package_ref` branch, tag або full commit SHA з вибраним `workflow_ref` harness
|
||||
- `source=url`: download HTTPS `.tgz` з обов’язковим `package_sha256`
|
||||
- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
|
||||
|
||||
`OpenClaw Release Checks` запускає Package Acceptance із `source=artifact`, підготовленим 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=release-history`, `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. Це GitHub-native replacement для більшої частини package/update coverage, яка раніше потребувала Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding, installer і platform behavior, але package/update product validation має надавати перевагу Package Acceptance.
|
||||
`OpenClaw 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=release-history`, `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 проти того самого розв’язаного tarball. Це GitHub-native заміна для більшості покриття package/update, яке раніше вимагало Parallels. Cross-OS release checks досі важливі для OS-specific onboarding, installer і platform behavior, але product validation package/update має віддавати перевагу Package Acceptance.
|
||||
|
||||
Канонічний checklist для update і plugin validation — це
|
||||
[Тестування оновлень і плагінів](/uk/help/testing-updates-plugins). Використовуйте його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить зміну plugin install/update, doctor cleanup або published-package migration.
|
||||
Канонічний checklist для update і Plugin validation —
|
||||
[Тестування оновлень і Plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить plugin install/update, doctor cleanup або published-package migration change. Вичерпна published update migration з кожного stable пакета `2026.4.23+` — це окремий ручний workflow `Update Migration`, а не частина Full Release CI.
|
||||
|
||||
Legacy package-acceptance leniency навмисно обмежено в часі. Packages до `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих у 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`. Published package `2026.4.26` може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати modern package contracts; ті самі gaps провалюють release validation.
|
||||
Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих в npm: private QA inventory entries, відсутні в tarball, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній збережений `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати про local build metadata stamp files, які вже були відвантажені. Пізніші пакети мають відповідати сучасним package contracts; ті самі прогалини провалюють release validation.
|
||||
|
||||
Використовуйте ширші Package Acceptance profiles, коли release question стосується фактичного installable package:
|
||||
Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується фактичного installable package:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -403,81 +404,79 @@ gh workflow run package-acceptance.yml \
|
||||
|
||||
Поширені package profiles:
|
||||
|
||||
- `smoke`: швидкі package install/channel/agent, Gateway network і config reload lanes
|
||||
- `package`: install/update/plugin package contracts без live ClawHub; це release-check
|
||||
default
|
||||
- `product`: `package` плюс MCP channels, Cron/subagent cleanup, OpenAI web
|
||||
search і OpenWebUI
|
||||
- `smoke`: швидкі package install/channel/agent, gateway network і config reload lanes
|
||||
- `package`: контракти install/update/plugin package без live ClawHub; це стандарт release-check
|
||||
- `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web search і OpenWebUI
|
||||
- `full`: Docker release-path chunks з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для сфокусованих reruns
|
||||
- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
|
||||
|
||||
Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або `telegram_mode=live-frontier` у Package Acceptance. Workflow передає resolved tarball `package-under-test` у Telegram lane; standalone Telegram workflow і далі приймає published npm spec для post-publish checks.
|
||||
Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або `telegram_mode=live-frontier` у Package Acceptance. Workflow передає розв’язаний tarball `package-under-test` у Telegram lane; standalone Telegram workflow досі приймає published npm spec для post-publish checks.
|
||||
|
||||
## Вхідні дані NPM workflow
|
||||
## Вхідні параметри NPM workflow
|
||||
|
||||
`OpenClaw NPM Release` приймає такі operator-controlled inputs:
|
||||
|
||||
- `tag`: обов’язковий 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`, це також може бути поточний
|
||||
full 40-character workflow-branch commit SHA для validation-only preflight
|
||||
- `preflight_only`: `true` для лише validation/build/package, `false` для
|
||||
real publish path
|
||||
- `preflight_run_id`: обов’язковий у real publish path, щоб workflow повторно використовував
|
||||
prepared tarball з успішного preflight run
|
||||
- `npm_dist_tag`: npm target tag для publish path; за замовчуванням `beta`
|
||||
повний 40-символьний workflow-branch commit SHA для validation-only preflight
|
||||
- `preflight_only`: `true` для validation/build/package only, `false` для
|
||||
справжнього publish path
|
||||
- `preflight_run_id`: обов’язковий на справжньому publish path, щоб workflow повторно використовував
|
||||
підготовлений tarball з успішного preflight run
|
||||
- `npm_dist_tag`: цільовий npm tag для publish path; стандартно `beta`
|
||||
|
||||
`OpenClaw Release Checks` приймає такі operator-controlled inputs:
|
||||
|
||||
- `ref`: branch, tag або full commit SHA для перевірки. Secret-bearing checks
|
||||
вимагають, щоб resolved commit був доступний з OpenClaw branch або
|
||||
потребують, щоб розв’язаний commit був reachable з OpenClaw branch або
|
||||
release tag.
|
||||
|
||||
Правила:
|
||||
|
||||
- Stable і correction tags можуть публікуватися або в `beta`, або в `latest`
|
||||
- Beta prerelease tags можуть публікуватися лише в `beta`
|
||||
- Для `OpenClaw NPM Release` full commit SHA input дозволений лише коли
|
||||
- Для `OpenClaw NPM Release` вхідний full commit SHA дозволений лише коли
|
||||
`preflight_only=true`
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди є
|
||||
validation-only
|
||||
- Real publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
|
||||
workflow перевіряє ці metadata перед продовженням publish
|
||||
- Справжній publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
|
||||
workflow перевіряє, що metadata before publish продовжується
|
||||
|
||||
## Послідовність стабільного npm-релізу
|
||||
## Послідовність stable npm release
|
||||
|
||||
Під час створення stable npm release:
|
||||
Під час підготовки stable npm release:
|
||||
|
||||
1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
|
||||
- До створення тегу можна використати поточний повний SHA коміту гілки workflow
|
||||
для сухого запуску лише валідації workflow передперевірки
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного потоку спочатку beta або `latest` лише
|
||||
тоді, коли ви навмисно хочете виконати безпосередню стабільну публікацію
|
||||
- До появи тегу можна використати поточний повний SHA коміту гілки workflow
|
||||
для пробного запуску workflow попередньої перевірки лише для валідації
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного потоку спочатку `beta`, або `latest` лише
|
||||
коли ви навмисно хочете виконати пряму стабільну публікацію
|
||||
3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному
|
||||
SHA коміту, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
|
||||
Matrix і покриття Telegram з одного ручного workflow
|
||||
SHA коміту, коли вам потрібне звичайне CI разом із покриттям live prompt cache, Docker, QA Lab,
|
||||
Matrix і Telegram з одного ручного workflow
|
||||
4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть
|
||||
ручний workflow `CI` на посиланні релізу
|
||||
ручний workflow `CI` на ref релізу
|
||||
5. Збережіть успішний `preflight_run_id`
|
||||
6. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
|
||||
6. Запустіть `OpenClaw NPM Release` ще раз із `preflight_only=false`, тим самим
|
||||
`tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
|
||||
7. Якщо реліз потрапив на `beta`, використайте приватний workflow
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
|
||||
щоб просунути цю стабільну версію з `beta` до `latest`
|
||||
8. Якщо реліз навмисно опубліковано безпосередньо до `latest`, а `beta`
|
||||
має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний
|
||||
щоб підвищити цю стабільну версію з `beta` до `latest`
|
||||
8. Якщо реліз навмисно опубліковано безпосередньо в `latest`, а `beta`
|
||||
має негайно відповідати тій самій стабільній збірці, використайте той самий приватний
|
||||
workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
|
||||
самовідновлюваній синхронізації перемістити `beta` пізніше
|
||||
|
||||
Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, оскільки вона все ще
|
||||
Мутація dist-tag розташована в приватному репозиторії з міркувань безпеки, оскільки вона все ще
|
||||
потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
|
||||
|
||||
Це робить і шлях прямої публікації, і шлях просування спочатку beta
|
||||
задокументованими та видимими для оператора.
|
||||
Це зберігає як шлях прямої публікації, так і шлях просування спочатку через beta
|
||||
задокументованими й видимими для оператора.
|
||||
|
||||
Якщо maintainer має повернутися до локальної npm-автентифікації, виконуйте будь-які команди
|
||||
1Password CLI (`op`) лише всередині окремої сесії tmux. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; утримання його всередині tmux робить підказки,
|
||||
сповіщення й обробку OTP видимими та запобігає повторним сповіщенням хоста.
|
||||
Якщо maintainer мусить повернутися до локальної автентифікації npm, запускайте будь-які команди 1Password
|
||||
CLI (`op`) лише всередині окремої сесії tmux. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; утримання його всередині tmux робить prompts,
|
||||
alerts і обробку OTP видимими та запобігає повторним alerts хоста.
|
||||
|
||||
## Публічні посилання
|
||||
|
||||
@ -495,6 +494,6 @@ Maintainers використовують приватну документаці
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
для фактичного runbook.
|
||||
|
||||
## Пов'язане
|
||||
## Пов’язане
|
||||
|
||||
- [Канали релізів](/uk/install/development-channels)
|
||||
|
||||
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue
Block a user