diff --git a/docs/uk/ci.md b/docs/uk/ci.md index a7b4a179c..c5398151b 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,178 +1,183 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося - - Ви налагоджуєте невдалі перевірки GitHub Actions -summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд + - Вам потрібно зрозуміти, чому CI-завдання запустилося або не запустилося + - Ви налагоджуєте перевірки GitHub Actions, що не проходять +summary: Граф завдань CI, гейти за областю дії та локальні еквіваленти команд title: CI-конвеєр x-i18n: - generated_at: "2026-04-29T10:40:27Z" + generated_at: "2026-04-29T11:37:33Z" model: gpt-5.5 provider: openai - source_hash: 4e4b9dae0e16e5ae701c4dbe5966ac9c4b3d8a3292f1804eef8f595616170e43 + source_hash: f3240aa7058dc4f624c45a400cac7a5b2cbbe442a7e17f3f0e1858cc9a876129 source_path: ci.md workflow: 16 --- -CI запускається під час кожного push до `main` і кожного pull request. Вона використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний звичайний граф CI для реліз-кандидатів або широкої перевірки, з Android-напрямками, що вмикаються через `include_android` для окремих ручних запусків. Релізні напрямки попереднього релізу Plugin живуть в окремому workflow `Plugin Prerelease` і запускаються лише з `Full Release Validation` або явного ручного dispatch. +CI запускається під час кожного push до `main` і кожного pull request. Вона використовує розумне обмеження області, щоб пропускати витратні завдання, коли змінилися лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний звичайний граф CI для реліз-кандидатів або широкої валідації, причому Android-доріжки вмикаються через `include_android` для окремих ручних запусків. Доріжки передрелізів Plugin лише для релізів живуть в окремому workflow `Plugin Prerelease` і запускаються тільки з `Full Release Validation` або явного ручного dispatch. -Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений на останній версії Knip, яку використовує цей скрипт, із вимкненим мінімальним віком релізу pnpm для встановлення через `dlx`. Він також запускає `pnpm deadcode:unused-files`, який порівнює production-знахідки Knip щодо невикористаних файлів із `scripts/deadcode-unused-files.allowlist.mjs`. Цей захист падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис у allowlist після очищення, зберігаючи при цьому навмисні поверхні динамічних plugin, згенеровані, build, live-test і package bridge, які Knip не може статично розв’язати. +Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений на останній версії Knip, яку використовує цей script, з вимкненим мінімальним віком релізу pnpm для встановлення `dlx`. Він також запускає `pnpm deadcode:unused-files`, що порівнює production-знахідки Knip щодо невикористаних файлів із `scripts/deadcode-unused-files.allowlist.mjs`. Цей захист падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist після очищення, водночас зберігаючи навмисні динамічні поверхні Plugin, generated, build, live-test і package bridge, які Knip не може статично розв’язати. -`Full Release Validation` — це ручний umbrella workflow для «запустити все -перед релізом». Він приймає branch, tag або повний commit SHA, запускає ручний -workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізних доказів -plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install -smoke, package acceptance, Docker-наборів релізного шляху, live/E2E, OpenWebUI, -QA Lab parity, Matrix і Telegram напрямків. Він також може запустити післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано -специфікацію опублікованого пакета. `release_profile=minimum|stable|full` керує широтою live/provider, -яку передають у release checks: `minimum` залишає найшвидші релізно-критичні -напрямки OpenAI/core, `stable` додає стабільний набір provider/backend, а -`full` запускає широку advisory-матрицю provider/media. Umbrella записує id -запущених дочірніх run, а фінальне завдання `Verify full validation` повторно -перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань -для кожного дочірнього run. Якщо дочірній workflow перезапустили і він став -зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат -umbrella і підсумок часу. +`Full Release Validation` — це ручний umbrella workflow для "запустити все +перед релізом." Він приймає гілку, tag або повний commit SHA, dispatch-ить +ручний workflow `CI` з цією ціллю, dispatch-ить `Plugin Prerelease` для +релізних доказів Plugin/package/static/Docker і dispatch-ить +`OpenClaw Release Checks` для install smoke, package acceptance, Docker +release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram +lanes. Він також може запускати post-publish workflow `NPM Telegram Beta E2E`, коли надано +опублікований package spec. `release_profile=minimum|stable|full` керує шириною live/provider, +переданою в release checks: `minimum` зберігає найшвидші критичні для релізу доріжки OpenAI/core, +`stable` додає стабільний набір provider/backend, а +`full` запускає широку advisory provider/media matrix. Umbrella записує +ids запущених child run, а фінальне завдання `Verify full validation` повторно перевіряє +поточні висновки child run і додає таблиці найповільніших завдань для кожного child +run. Якщо child workflow перезапущено і він став зеленим, перезапустіть лише parent +verifier job, щоб оновити результат umbrella і timing summary. Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для -звичайного дочірнього full CI, `release-checks` для кожного релізного дочірнього -workflow або вужчу релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, -`qa-parity`, `qa-live` або `npm-telegram` на umbrella. Це тримає перезапуск -невдалого релізного box обмеженим після сфокусованого виправлення. +звичайного full CI child, `release-checks` для кожного release child або вужчу +release group: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, +`qa-parity`, `qa-live` або `npm-telegram` в umbrella. Це утримує перезапуск failed +release box у межах після точкового виправлення. -Дочірній live/E2E для релізу зберігає широке native-покриття `pnpm test:live`, але -запускає його як іменовані шарди (`native-live-src-agents`, -`native-live-src-gateway-core`, відфільтровані за provider -завдання `native-live-src-gateway-profiles`, +Release live/E2E child зберігає широке native покриття `pnpm test:live`, але +запускає його як named shards (`native-live-src-agents`, +`native-live-src-gateway-core`, provider-filtered +`native-live-src-gateway-profiles` jobs, `native-live-src-gateway-backends`, `native-live-test`, `native-live-extensions-a-k`, `native-live-extensions-l-n`, `native-live-extensions-openai`, `native-live-extensions-o-z-other`, -`native-live-extensions-xai`, розділені audio/video-шарди media та -відфільтровані за provider шарди music) через `scripts/test-live-shard.mjs` -замість одного послідовного завдання. Це зберігає те саме файлове покриття, але -полегшує перезапуск і діагностику повільних збоїв live provider. Агреговані -назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і -`native-live-extensions-media-music` залишаються чинними для ручних -одноразових перезапусків. +`native-live-extensions-xai`, розділені media audio/video shards і +provider-filtered music shards) через `scripts/test-live-shard.mjs` замість +одного serial job. Це зберігає те саме файлове покриття, водночас полегшуючи повторний запуск +і діагностику повільних live provider failures. Aggregate +`native-live-extensions-o-z`, `native-live-extensions-media` і +`native-live-extensions-media-music` shard names залишаються чинними для ручних +one-shot reruns. -Native live media-шарди запускаються в -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow -`Live Media Runner Image`. Цей image попередньо встановлює `ffmpeg` і -`ffprobe`; media-завдання лише перевіряють binaries перед setup. Тримайте live-набори з Docker-підтримкою на звичайних Blacksmith runners, бо container jobs — неправильне місце для запуску вкладених Docker tests. +Native live media shards запускаються в +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який збирає +workflow `Live Media Runner Image`. Цей image попередньо встановлює `ffmpeg` і +`ffprobe`; media jobs лише перевіряють binaries перед setup. Тримайте Docker-backed +live suites на звичайних Blacksmith runners, бо container jobs — неправильне +місце для запуску nested Docker tests. -Live model/backend-шарди з Docker-підтримкою використовують окремий спільний -image `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного commit. Live -release workflow збирає і публікує цей image один раз, потім Docker live model, -gateway, CLI backend, ACP bind і Codex harness-шарди запускаються з -`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну -source Docker target, release run налаштовано неправильно, і він витратить wall +Docker-backed live model/backend shards використовують окремий спільний +image `ghcr.io/openclaw/openclaw-live-test:` для вибраного commit. Live +release workflow збирає і публікує цей image один раз, після чого Docker live model, +gateway, CLI backend, ACP bind і Codex harness shards запускаються з +`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці shards незалежно перебудовують повну source Docker +target, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані image builds. -`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз -розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає -цей artifact і в live/E2E workflow релізного шляху для Docker, і в шард package acceptance. Це зберігає байти пакета узгодженими між release boxes і -уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний +ref у tarball `release-package-under-test`, а потім передає цей artifact +і live/E2E release-path Docker workflow, і package acceptance +shard. Це зберігає package bytes узгодженими між release boxes і уникає +повторного пакування того самого candidate у кількох child jobs. -`Package Acceptance` — це side-run workflow для перевірки artifact пакета -без блокування release workflow. Він розв’язує одного кандидата з -опублікованої npm spec, trusted `package_ref`, зібраного з вибраним +`Package Acceptance` — це side-run workflow для валідації package artifact +без блокування release workflow. Він розв’язує один candidate з +опублікованого npm spec, trusted `package_ref`, зібраного з вибраним `workflow_ref` harness, HTTPS tarball URL із SHA-256 або tarball artifact з іншого GitHub Actions run, завантажує його як `package-under-test`, а потім повторно використовує -Docker release/E2E scheduler з цим tarball замість повторного пакування -workflow checkout. Профілі покривають smoke, package, product, full і custom -вибори Docker lanes. Профіль `package` використовує offline-покриття plugin, тому -перевірка опублікованого пакета не залежить від доступності live ClawHub. Опційний -напрямок Telegram повторно використовує artifact `package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях -опублікованої npm spec зберігається для standalone dispatch. +Docker release/E2E scheduler із цим tarball замість повторного пакування +workflow checkout. Profiles покривають smoke, package, product, full і custom +Docker lane selections. Profile `package` використовує offline plugin coverage, щоб +валідація published-package не залежала від live доступності ClawHub. Optional Telegram lane повторно використовує +artifact `package-under-test` у workflow `NPM Telegram Beta E2E`, а +published npm spec path зберігається для standalone dispatches. -## Приймальне тестування пакета +## Приймання package -Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей встановлюваний пакет OpenClaw -як продукт?» Це відрізняється від звичайної CI: звичайна CI перевіряє -дерево source, тоді як package acceptance перевіряє один tarball через той самий -Docker E2E harness, який користувачі задіюють після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить як "чи працює цей installable package OpenClaw +як product?" Це відрізняється від звичайної CI: звичайна CI перевіряє +source tree, тоді як package acceptance перевіряє один tarball через той самий +Docker E2E harness, який користувачі запускають після встановлення або оновлення. -Workflow має чотири завдання: +Workflow має чотири jobs: -1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного package-кандидата, +1. `resolve_package` checkout-ить `workflow_ref`, розв’язує один package candidate, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує - `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як artifact - `package-under-test` і друкує source, workflow ref, package + `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як + artifact `package-under-test` і друкує source, workflow ref, package ref, version, SHA-256 і profile у GitHub step summary. 2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує - цей artifact, перевіряє інвентар tarball, готує package-digest - Docker images за потреби та запускає вибрані Docker lanes проти цього - package замість пакування workflow checkout. Коли профіль вибирає - кілька цільових `docker_lanes`, reusable workflow готує package - і спільні images один раз, а потім розгортає ці lanes як паралельні цільові Docker + цей artifact, перевіряє tarball inventory, готує package-digest + Docker images за потреби і запускає вибрані Docker lanes проти цього + package замість пакування workflow checkout. Коли profile вибирає + кілька targeted `docker_lanes`, reusable workflow готує package + і shared images один раз, а потім розгортає ці lanes як parallel targeted Docker jobs з унікальними artifacts. -3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли - `telegram_mode` не є `none`, і встановлює той самий artifact `package-under-test`, - якщо Package Acceptance розв’язав його; standalone Telegram dispatch - все ще може встановити опубліковану npm spec. +3. `package_telegram` optionally викликає `NPM Telegram Beta E2E`. Він запускається, коли + `telegram_mode` не `none`, і встановлює той самий artifact `package-under-test`, + коли Package Acceptance розв’язав його; standalone Telegram dispatch + усе ще може встановити published npm spec. 4. `summary` провалює workflow, якщо package resolution, Docker acceptance або - опційний Telegram lane завершилися невдало. + optional Telegram lane failed. -Джерела кандидатів: +Candidate sources: - `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну - release-версію OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для - acceptance опублікованих beta/stable. -- `source=ref`: пакує trusted `package_ref` branch, tag або повний commit SHA. + версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для + published beta/stable acceptance. +- `source=ref`: пакує trusted `package_ref` branch, tag або full commit SHA. Resolver fetch-ить branches/tags OpenClaw, перевіряє, що вибраний commit - досяжний з repository branch history або release tag, встановлює deps у + reachable з repository branch history або release tag, встановлює deps у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. +- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` required. - `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і - `artifact_name`; `package_sha256` опційний, але його варто надати для - artifact, поширених зовні. + `artifact_name`; `package_sha256` optional, але його варто надати для + externally shared artifacts. Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted -код workflow/harness, який запускає test. `package_ref` — це source commit, -який пакують, коли `source=ref`. Це дозволяє поточному test harness перевіряти -старіші trusted source commits без запуску старої workflow logic. +workflow/harness code, що запускає test. `package_ref` — це source commit, +який пакується, коли `source=ref`. Це дає змогу current test harness перевіряти +старіші trusted source commits без запуску old workflow logic. -Профілі відповідають Docker-покриттю: +Profiles map to Docker coverage: - `smoke`: `npm-onboard-channel-agent`, `gateway-network`, `config-reload` - `package`: `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` -- `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, +- `product`: `package` plus `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full`: повні chunks релізного Docker-шляху з OpenWebUI -- `custom`: точні `docker_lanes`; обов’язково, коли `suite_profile=custom` +- `full`: full Docker release-path chunks with OpenWebUI +- `custom`: exact `docker_lanes`; required when `suite_profile=custom` Release checks викликають Package Acceptance з `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і -`telegram_mode=mock-openai`. Docker -chunks релізного шляху покривають перетин package/update/plugin lanes, тоді як Package -Acceptance зберігає artifact-native доказ bundled-channel compat, offline plugin і -Telegram проти того самого розв’язаного package tarball. -Cross-OS release checks і далі покривають OS-специфічне onboarding, installer і -platform behavior; product-перевірку package/update слід починати з Package +`telegram_mode=mock-openai`. Release-path Docker +chunks покривають overlapping package/update/plugin lanes, тоді як Package +Acceptance зберігає artifact-native bundled-channel compat, offline plugin і +Telegram proof проти того самого resolved package tarball. +Cross-OS release checks усе ще покривають OS-specific onboarding, installer і +platform behavior; package/update product validation має починатися з Package Acceptance. Windows packaged і installer fresh lanes також перевіряють, що -встановлений package може імпортувати browser-control override з сирого absolute -Windows path. +installed package може імпортувати browser-control override з raw absolute +Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує +`OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено, інакше `openai/gpt-5.4-mini`, щоб +install і Gateway proof залишалися швидкими й детермінованими. Dedicated live +provider/model lanes усе ще покривають ширший model routing, включно з повільнішими +frontier defaults. -Package Acceptance має обмежені вікна legacy-сумісності для вже -опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, -можуть використовувати compatibility path для відомих private QA entries у -`dist/postinstall-inventory.json`, які вказують на файли, omitted from tarball, -`doctor-switch` може пропустити підвипадок persistence `gateway install --wrapper`, -коли package не expose-ить цей flag, `update-channel-switch` може prune-ити -відсутні `pnpm.patchedDependencies` з fake git fixture, отриманої з tarball, і -може логувати відсутній persisted `update.channel`, plugin smokes можуть читати legacy -install-record locations або приймати відсутню marketplace install-record -persistence, а `plugin-update` може дозволити config metadata migration, усе ще -вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. Опублікований -package `2026.4.26` також може попереджати про local build metadata stamp files, -які вже було shipped. Пізніші packages мають відповідати сучасним contracts; ті -самі умови дають failure замість warn або skip. +Package Acceptance має bounded legacy-compatibility windows для вже +published packages. Packages through `2026.4.25`, including `2026.4.25-beta.*`, +may use the compatibility path for known private QA entries in +`dist/postinstall-inventory.json` that point at tarball-omitted files, +`doctor-switch` may skip the `gateway install --wrapper` persistence subcase +when the package does not expose that flag, `update-channel-switch` may prune +missing `pnpm.patchedDependencies` from the tarball-derived fake git fixture and +may log missing persisted `update.channel`, plugin smokes may read legacy +install-record locations or accept missing marketplace install-record +persistence, and `plugin-update` may allow config metadata migration while still +requiring the install record and no-reinstall behavior to stay unchanged. Later packages must satisfy the modern contracts; the +same conditions fail instead of warn or skip. Приклади: @@ -215,121 +220,99 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: -`.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали смуг, часові -показники фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або -точних Docker-смуг замість повторного запуску повної перевірки релізу. +Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: +`.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної валідації релізу. -QA Lab має окремі смуги CI поза основним workflow із розумним визначенням області. Workflow -`Parity gate` запускається для відповідних змін у PR і вручну; він -збирає приватне середовище виконання QA та порівнює мокові агентні набори GPT-5.5 і Opus 4.6. -Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і -вручну; він розгортає моковий parity gate, живу смугу Matrix, а також живі -смуги Telegram і Discord як паралельні завдання. Живі завдання використовують середовище -`qa-live-shared`, а Telegram/Discord використовують оренди Convex. Перевірки релізу запускають -живі транспортні смуги Matrix і Telegram з детермінованим моковим -провайдером і моделями з мок-кваліфікацією (`mock-openai/gpt-5.5` і -`mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки живої моделі -та звичайного запуску Plugin провайдера. Живий транспортний Gateway також -вимикає пошук у пам’яті, оскільки parity QA окремо покриває поведінку пам’яті; -підключення провайдера покривають окремі набори для живої моделі, нативного провайдера -та Docker-провайдера. Matrix використовує `--profile fast` для запланованих і релізних gates, -додаючи `--fail-fast` лише тоді, коли CLI з checkout це підтримує. Типове значення CLI -і ручний ввід workflow залишаються `all`; ручний dispatch `matrix_profile=all` -завжди шардить повне покриття Matrix на завдання `transport`, `media`, -`e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також -запускає критично важливі для релізу смуги QA Lab перед схваленням релізу; його QA parity -gate запускає кандидатний і базовий набори як паралельні завдання смуг, потім завантажує -обидва артефакти в невелике завдання звіту для фінального порівняння parity. -Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не -торкається середовища виконання QA, parity наборів моделей або поверхні, якою володіє parity workflow. -Для звичайних виправлень каналів, конфігурації, документації або юніт-тестів сприймайте це як необов’язковий -сигнал і дотримуйтеся доказів scoped CI/check. +QA Lab має окремі CI lanes поза основним smart-scoped workflow. Workflow `Parity gate` запускається для відповідних змін у PR і через manual dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6. 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 запускають Matrix і Telegram live transport lanes з детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` та +`mock-openai/gpt-5.5-alt`), щоб contract каналу був ізольований від затримки live model і звичайного запуску provider-Plugin. Live transport gateway також вимикає memory search, оскільки QA parity окремо покриває поведінку пам’яті; +provider connectivity покривається окремими наборами live model, native provider і Docker provider. Matrix використовує `--profile fast` для scheduled і release gates, +додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Значення CLI за замовчуванням і manual workflow input залишаються `all`; manual `matrix_profile=all` +dispatch завжди шардує повне покриття Matrix у jobs `transport`, `media`, +`e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед схваленням релізу; його QA parity +gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невеликий report job для фінального порівняння parity. +Не ставте шлях landing PR за `Parity gate`, якщо зміна справді не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. +Для звичайних виправлень каналів, конфігурації, документації або unit tests розглядайте це як опційний сигнал і дотримуйтеся scoped CI/check evidence. -Workflow `Duplicate PRs After Merge` — це ручний workflow мейнтейнера для -очищення дублікатів після landing. Типово він працює в dry-run і закриває лише явно -перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що -landed PR змерджено і що кожен дублікат має або спільне згадане issue, -або перекривні змінені hunks. +Workflow `Duplicate PRs After Merge` є manual maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює в dry-run і закриває лише явно перелічені PRs, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільне referenced issue, або перетин changed hunks. -Workflow `CodeQL` навмисно є вузьким сканером безпеки першого проходу, -а не повним скануванням репозиторію. Щоденні й ручні запуски сканують код workflow Actions -плюс найризикованіші поверхні JavaScript/TypeScript для auth, secrets, sandbox, cron і -gateway за допомогою високоточних security queries. Завдання -channel-runtime-boundary окремо сканує контракти реалізації core channel -плюс середовище виконання Plugin каналу, gateway, Plugin SDK, secrets і +Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, +а не повним скануванням репозиторію. Daily і manual runs сканують Actions workflow code +та найризикованіші JavaScript/TypeScript поверхні auth, secrets, sandbox, cron і gateway за допомогою high-precision security queries. Job +channel-runtime-boundary окремо сканує core channel implementation +contracts, а також channel Plugin runtime, gateway, Plugin SDK, secrets і audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, -щоб сигнал безпеки каналів міг масштабуватися без розширення базової -категорії JS/TS. +щоб сигнал безпеки каналів міг масштабуватися без розширення базової категорії +JS/TS. -Workflow `CodeQL Android Critical Security` — це запланований Android -security shard. Він вручну збирає Android-застосунок для CodeQL на найменшому -лейблі Blacksmith Linux runner, прийнятому workflow sanity, і завантажує результати +Workflow `CodeQL Android Critical Security` є scheduled Android +security shard. Він вручну збирає Android app для CodeQL на найменшому +Blacksmith Linux runner label, який приймає workflow sanity, і завантажує результати в категорію `/codeql-critical-security/android`. -Workflow `CodeQL macOS Critical Security` — це щотижневий/ручний macOS -security shard. Він вручну збирає macOS-застосунок для CodeQL на Blacksmith macOS, -відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує результати -в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним -типовим workflow, бо збірка macOS домінує за часом виконання навіть коли вона чиста. +Workflow `CodeQL macOS Critical Security` є weekly/manual macOS +security shard. Він вручну збирає macOS app для CodeQL на Blacksmith macOS, +відфільтровує dependency build results із завантаженого SARIF і завантажує результати +в категорію `/codeql-critical-security/macos`. Тримайте його поза daily +default workflow, оскільки macOS build домінує runtime навіть коли все чисто. -Workflow `CodeQL Critical Quality` — це відповідний shard не для безпеки. Він -запускає лише JavaScript/TypeScript quality queries із severity error та без security +Workflow `CodeQL Critical Quality` є відповідним non-security shard. Він +запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його -завдання core-auth-secrets сканує код меж auth, secrets, sandbox, cron і gateway security -в окремій категорії `/codeql-critical-quality/core-auth-secrets`. Завдання config-boundary -сканує схему конфігурації, міграцію, нормалізацію та контракти IO в -окремій категорії `/codeql-critical-quality/config-boundary`. Завдання -gateway-runtime-boundary сканує схеми протоколу gateway і контракти server method -в окремій категорії -`/codeql-critical-quality/gateway-runtime-boundary`. Завдання -channel-runtime-boundary сканує контракти реалізації core channel в -окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання -agent-runtime-boundary сканує виконання команд, dispatch моделей/провайдерів, -dispatch і черги auto-reply, а також контракти runtime control-plane ACP в -окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання -mcp-process-runtime-boundary сканує MCP servers і tool bridges, helpers supervision процесів -та контракти outbound delivery в окремій категорії -`/codeql-critical-quality/mcp-process-runtime-boundary`. Завдання +job core-auth-secrets сканує auth, secrets, sandbox, cron і gateway security +boundary code в окремій категорії `/codeql-critical-quality/core-auth-secrets`. +Job config-boundary +сканує config schema, migration, normalization та IO contracts в окремій +категорії `/codeql-critical-quality/config-boundary`. Job +gateway-runtime-boundary сканує gateway protocol schemas і server method +contracts в окремій +категорії `/codeql-critical-quality/gateway-runtime-boundary`. Job +channel-runtime-boundary сканує core channel implementation contracts в +окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Job +agent-runtime-boundary сканує command execution, model/provider dispatch, +auto-reply dispatch і queues, а також ACP control-plane runtime contracts в +окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Job +mcp-process-runtime-boundary сканує MCP servers і tool bridges, process +supervision helpers та outbound delivery contracts в окремій +категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Job memory-runtime-boundary сканує memory host SDK, memory runtime facades, -аліаси memory Plugin SDK, зв’язувальний код активації memory runtime і команди memory doctor -в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. -Завдання ui-control-plane сканує bootstrap Control UI, локальне збереження, control flows gateway -і runtime-контракти task control-plane в окремій категорії -`/codeql-critical-quality/ui-control-plane`. Завдання +memory Plugin SDK aliases, memory runtime activation glue і memory doctor +commands в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. +Job +ui-control-plane сканує Control UI bootstrap, local persistence, gateway +control flows і task control-plane runtime contracts в окремій +категорії `/codeql-critical-quality/ui-control-plane`. Job web-media-runtime-boundary сканує core web fetch/search, media IO, media understanding, image-generation і media-generation runtime contracts в -окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Завдання -plugin-boundary сканує контракти loader, registry, public-surface і entrypoint Plugin SDK -в окремій категорії `/codeql-critical-quality/plugin-boundary`. +окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Job +plugin-boundary сканує loader, registry, public-surface і Plugin SDK +entrypoint contracts в окремій категорії `/codeql-critical-quality/plugin-boundary`. Тримайте workflow окремо від security, щоб quality findings можна було -планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. +планувати, вимірювати, вимикати або розширювати без затемнення security signal. Розширення CodeQL для Swift, Python і bundled-Plugin слід додавати назад як -scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний -час виконання та сигнал. +scoped або sharded follow-up work лише після того, як вузькі profiles матимуть стабільні +runtime і signal. -Workflow `Docs Agent` — це подієво-керована смуга обслуговування Codex для підтримання -наявної документації в узгодженому стані з нещодавно landing-змінами. Він не має чистого розкладу: -успішний non-bot push CI run на `main` може його запустити, а manual dispatch може -запустити його напряму. Workflow-run invocations пропускаються, коли `main` просунувся далі або коли -інший non-skipped запуск Docs Agent було створено за останню годину. Коли він запускається, він -переглядає діапазон комітів від попереднього non-skipped source SHA Docs Agent до -поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з -останнього проходу документації. +Workflow `Docs Agent` є event-driven Codex maintenance lane для підтримання +наявної документації узгодженою з нещодавно landed changes. Він не має чистого schedule: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може +запустити його безпосередньо. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли +інший non-skipped Docs Agent run було створено протягом останньої години. Коли він запускається, він +переглядає commit range від попереднього non-skipped Docs Agent source SHA до +поточного `main`, тож один hourly run може покрити всі main changes, накопичені після +останнього docs pass. -Workflow `Test Performance Agent` — це подієво-керована смуга обслуговування Codex -для повільних тестів. Він не має чистого розкладу: успішний non-bot push CI run на -`main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже -запускався або виконується того UTC дня. Manual dispatch обходить цей щоденний gate активності. -Смуга будує full-suite grouped Vitest performance report, дозволяє Codex -робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких -рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують -базову кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти -лише очевидні failures, і after-agent full-suite report має пройти, перш ніж -щось буде закомічено. Коли `main` просувається до landing bot push, смуга -rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; -конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex -міг зберегти ту саму drop-sudo safety posture, що й docs agent. +Workflow `Test Performance Agent` є event-driven Codex maintenance lane +для повільних tests. Він не має чистого schedule: успішний non-bot push CI run на +`main` може його запустити, але він пропускається, якщо інша workflow-run invocation уже +запускалася або виконується цього UTC day. Manual dispatch обходить цей daily activity +gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex +робити лише невеликі coverage-preserving test performance fixes замість широких +refactors, потім повторно запускає full-suite report і відхиляє зміни, які зменшують +passing baseline test count. Якщо baseline має failing tests, Codex може виправляти +лише очевидні failures, а after-agent full-suite report має пройти перед +будь-яким commit. Коли `main` просувається до того, як bot push потрапить у репозиторій, lane +rebase-ить validated patch, повторно запускає `pnpm check:changed` і повторює push; +conflicting stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex +action міг зберегти таку саму drop-sudo safety posture, як docs agent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -338,46 +321,46 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Огляд завдань +## Огляд jobs | Завдання | Призначення | Коли запускається | | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє docs-only зміни, змінені області, змінені Plugins і будує маніфест CI | Завжди для non-draft pushes і PRs | -| `security-scm-fast` | Виявлення приватних ключів і audit workflow через `zizmor` | Завжди для non-draft pushes і PRs | -| `security-dependency-audit` | Production lockfile audit без залежностей за npm advisories | Завжди для non-draft pushes і PRs | -| `security-fast` | Обов’язковий aggregate для швидких security jobs | Завжди для non-draft pushes і PRs | -| `build-artifacts` | Збірка `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-relevant changes | -| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-relevant changes | -| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-relevant changes | -| `checks-node-core-test` | Core Node test shards, за винятком channel, bundled, contract і extension lanes | Node-relevant changes | -| `check` | Sharded еквівалент основного local gate: prod types, lint, guards, test types і strict smoke | Node-relevant changes | -| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-relevant changes | -| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-relevant changes | -| `checks` | Verifier для built-artifact channel tests | Node-relevant changes | -| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Manual CI dispatch for releases | -| `check-docs` | Docs formatting, lint і broken-link checks | Docs changed | -| `skills-python` | Ruff + pytest для Python-backed skills | Python-skill-relevant changes | -| `checks-windows` | Windows-specific process/path tests плюс regressions shared runtime import specifier | Windows-relevant changes | -| `macos-node` | macOS TypeScript test lane з використанням спільних built artifacts | macOS-relevant changes | -| `macos-swift` | Swift lint, build і tests для macOS app | macOS-relevant changes | -| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-relevant changes | -| `test-performance-agent` | Щоденна Codex slow-test optimization після trusted activity | Main CI success or manual dispatch | +| `preflight` | Виявляє зміни лише в документації, змінені області, змінені розширення та збирає CI-маніфест | Завжди для нечернеткових push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR | +| `security-dependency-audit` | Аудит production lockfile без залежностей за advisories npm | Завжди для нечернеткових push і PR | +| `security-fast` | Обов'язковий агрегат для швидких завдань безпеки | Завжди для нечернеткових push і PR | +| `build-artifacts` | Збирає `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані downstream-артефакти | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/Plugin-contract/protocol | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | +| `checks-node-core-test` | Шарди тестів core Node, крім ліній каналів, bundled, контрактів і розширень | Зміни, релевантні для Node | +| `check` | Шардований еквівалент головного локального gate: prod-типи, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Архітектура, межі, guards поверхні розширень, package-boundary і шарди gateway-watch | Зміни, релевантні для Node | +| `build-smoke` | Smoke-тести зібраного CLI і smoke startup-memory | Зміни, релевантні для Node | +| `checks` | Верифікатор для тестів каналів зібраних артефактів | Зміни, релевантні для Node | +| `checks-node-compat-node22` | Лінія збірки й smoke для сумісності з Node 22 | Ручний запуск CI для релізів | +| `check-docs` | Перевірки форматування документації, lint і broken-link | Змінено документацію | +| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python-Skills | +| `checks-windows` | Специфічні для Windows тести процесів/шляхів плюс спільні регресії runtime import specifier | Зміни, релевантні для Windows | +| `macos-node` | Лінія тестів TypeScript для macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, збірка й тести для застосунку macOS | Зміни, релевантні для macOS | +| `android` | Unit-тести Android для обох flavor плюс одна debug APK-збірка | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успішний main CI або ручний запуск | -Manual CI-диспетчеризації виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну -не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, channel -contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки docs, -Python Skills, Windows, macOS і Control UI i18n. Окремі manual CI -dispatches запускають лише Android із `include_android=true`; повна release -umbrella вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, -release-only шард `agentic-plugins`, повний batch sweep для extension -і Docker lanes для prerelease Plugin виключені з CI. Docker -prerelease suite запускається лише тоді, коли `Full Release Validation` диспетчеризує -окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. -Manual runs використовують -унікальну concurrency group, щоб повний suite release-candidate не скасовувався -іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає -довіреному викликачеві змогу запускати цей граф для branch, tag або повного commit SHA, водночас -використовуючи файл workflow з вибраного dispatch ref. +Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну +область не для Android: шарди Linux Node, шарди bundled-Plugin, контракти каналів, +сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, +Python Skills, Windows, macOS та i18n Control UI. Окремі ручні запуски CI +виконують лише Android із `include_android=true`; повна release umbrella +вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, +релізний шард `agentic-plugins`, повний пакетний sweep розширень +і Docker-лінії prerelease для Plugin виключено з CI. Docker-набір prerelease +запускається лише тоді, коли `Full Release Validation` запускає +окремий workflow `Plugin Prerelease` із увімкненим gate release-validation. +Ручні запуски використовують +унікальну concurrency group, щоб повний набір release-candidate не було скасовано +іншим push або PR-запуском на тому самому ref. Необов'язковий input `target_ref` дає +довіреному caller змогу запускати цей граф для branch, tag або повного commit SHA, +використовуючи workflow-файл з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -387,66 +370,66 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Порядок fail-fast -Jobs упорядковані так, щоб дешеві перевірки падали до запуску дорогих: +Завдання впорядковано так, щоб дешеві перевірки падали до запуску дорогих: -1. `preflight` визначає, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є steps всередині цього job, а не окремими 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 могли стартувати щойно спільна build буде готова. -4. Важчі platform і runtime lanes розгалужуються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи на важчі matrix-завдання артефактів і платформ. +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`. -Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. -Manual dispatch пропускає changed-scope detection і змушує preflight manifest -діяти так, ніби кожна scoped area змінилася. -Редагування CI workflow перевіряють граф Node CI плюс workflow linting, але самі по собі не примушують запускати нативні builds Windows, Android або macOS; ці platform lanes залишаються scoped до змін platform source. -CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits використовують швидкий Node-only manifest path: preflight, security і одне завдання `checks-fast-core`. Цей path уникає build artifacts, сумісності Node 22, channel contracts, повних core shards, bundled-plugin shards і додаткових guard matrices, коли змінені файли обмежені routing або helper surfaces, які швидке завдання перевіряє безпосередньо. -Windows Node checks scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes, щоб вони не резервували 16-vCPU Windows worker для coverage, який уже перевіряється звичайними test shards. -Окремий workflow `install-smoke` повторно використовує той самий scope script через власний job `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають fast path для Docker/package surfaces, змін bundled plugin package/manifest, а також core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only зміни bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє bundled extension build arg і запускає обмежений bundled-plugin Docker profile під сукупним command timeout 240 секунд, причому Docker run кожного scenario обмежений окремо. Full path залишає QR package install і installer Docker/update coverage для nightly scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді торкаються installer/package/Docker surfaces. Pushes у `main`, зокрема merge commits, не примушують full path; коли changed-scope logic запросила б full coverage на push, workflow залишає fast Docker smoke і передає full install smoke nightly або release validation. Повільний Bun global install image-provider smoke окремо gate-иться через `run_bun_global_install_smoke`; він запускається за nightly schedule і з release checks workflow, а manual `install-smoke` dispatches можуть увімкнути його, але pull requests і pushes у `main` його не запускають. QR і installer Docker tests зберігають власні install-focused Dockerfiles. Локальний `test:docker:all` попередньо збирає один спільний live-test image, пакує OpenClaw один раз як npm tarball і збирає два спільні images `scripts/e2e/Dockerfile`: bare Node/Git runner для installer/update/plugin-dependency lanes і functional image, який встановлює той самий tarball у `/app` для normal functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте стандартну main-pool slot count 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM` і provider-sensitive tail-pool slot count 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Heavy lane caps за замовчуванням мають значення `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service lanes не перенавантажували Docker, тоді як легші lanes усе ще заповнюють доступні slots. Одна lane, важча за effective caps, усе одно може стартувати з порожнього pool, а потім виконується самостійно, доки не звільнить capacity. Запуски lanes за замовчуванням рознесені на 2 секунди, щоб уникати локальних Docker daemon create storms; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний aggregate preflights Docker, видаляє застарілі OpenClaw E2E containers, виводить active-lane status, зберігає lane timings для longest-first ordering і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки scheduler. Він за замовчуванням припиняє планувати нові pooled lanes після першої failure, і кожна lane має fallback timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні scheduler lanes, зокрема release-only lanes, як-от `install-e2e`, і split bundled update lanes, як-от `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб agents могли відтворити одну failed lane. Reusable live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, які package, image kind, live image, lane і credential coverage потрібні, потім `scripts/docker-e2e.mjs` перетворює цей plan на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного run, або завантажує package artifact з `package_artifact_run_id`; перевіряє tarball inventory; збирає і пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість rebuild. Docker image pulls повторюються з обмеженим 180-секундним timeout на attempt, щоб завислий registry/cache stream швидко повторився, а не спожив більшість CI critical path. Workflow `Package Acceptance` є high-level package gate: він resolve-ить candidate з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або artifact попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна acceptance logic могла перевіряти старіші довірені commits без checkout старого workflow code. Release checks запускають custom Package Acceptance delta для target ref: bundled-channel compat, offline plugin fixtures і Telegram package QA для resolved tarball. Release-path Docker suite запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler (`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|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|bundled-channels`). OpenWebUI включається в `plugins-runtime-services`, коли full release-path coverage запитує це, і зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` досі працюють для manual reruns, але release workflow використовує split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували над critical path. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. Chunk `bundled-channels` запускає split lanes `bundled-channel-*` і `bundled-channel-update-*` замість серійної all-in-one lane `bundled-channel-deps`. Кожен chunk uploads `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input workflow `docker_lanes` запускає вибрані lanes на підготовлених images замість chunk jobs, що обмежує debugging failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього run; якщо вибрана lane є live Docker lane, targeted job збирає live-test image локально для цього rerun. Згенеровані per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати точні package і images з failed run. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts з GitHub run і вивести combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для slow-lane і phase critical-path summaries. Scheduled live/E2E workflow щодня запускає повний release-path Docker suite. Bundled update matrix розділена за update target, щоб repeated npm update і doctor repair passes могли shard-итися з іншими bundled checks. +Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. +Ручний запуск пропускає визначення changed-scope і змушує передпольотний маніфест +працювати так, ніби змінилася кожна область із визначеною областю дії. +Зміни CI workflow перевіряють граф Node CI та лінтинг workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні лінії залишаються прив’язаними до змін платформного вихідного коду. +Редагування, що стосуються лише маршрутизації CI, вибрані дешеві зміни фікстур core-тестів, а також вузькі зміни допоміжних засобів/маршрутизації тестів контракту plugin використовують швидкий шлях маніфесту лише для Node: передпольотна перевірка, безпека й один task `checks-fast-core`. Цей шлях уникає артефактів збірки, сумісності з Node 22, контрактів каналів, повних шардів core, шардів bundled-plugin і додаткових матриць захисту, коли змінені файли обмежені поверхнями маршрутизації або допоміжними поверхнями, які швидкий task перевіряє напряму. +Перевірки Windows Node обмежені специфічними для Windows обгортками процесів/шляхів, допоміжними засобами запуску npm/pnpm/UI, конфігурацією менеджера пакетів і поверхнями CI workflow, які виконують цю лінію; не пов’язані зміни вихідного коду, plugin, install-smoke і зміни лише тестів залишаються на лініях Linux Node, щоб вони не резервували 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними тестовими шардами. +Окремий workflow `install-smoke` повторно використовує той самий scope script через власний job `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin, а також поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише вихідного коду bundled plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним тайм-аутом команди 240 секунд, де Docker run кожного сценарію обмежено окремо. Повний шлях зберігає інсталяцію QR package і Docker/update-покриття інсталятора для нічних запланованих запусків, ручних запусків, workflow-call release checks і pull requests, які справді зачіпають поверхні installer/package/Docker. Пуші в `main`, зокрема merge commits, не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow залишає швидкий Docker smoke і передає повний install smoke нічній або release-валідації. Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з release checks workflow, а ручні запуски `install-smoke` можуть увімкнути його опційно, але pull requests і пуші в `main` його не запускають. QR і installer Docker tests зберігають власні Dockerfiles, зосереджені на інсталяції. Локальний `test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: базовий Node/Git runner для ліній installer/update/plugin-dependency і функціональний образ, який встановлює той самий tarball у `/app` для ліній звичайної функціональності. Визначення 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`; налаштовуйте стандартну кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-pool, чутливого до провайдера, 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких ліній за замовчуванням становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і багатосервісні лінії не перевантажували Docker, тоді як легші лінії все ще заповнюють доступні слоти. Одна лінія, важча за ефективні обмеження, все одно може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Старти ліній за замовчуванням зміщені на 2 секунди, щоб уникнути локальних піків створення в Docker daemon; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний сукупний запуск виконує передпольотну перевірку Docker, видаляє застарілі OpenClaw E2E containers, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших до найкоротших і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для інспекції планувальника. За замовчуванням він припиняє планувати нові pooled lanes після першої помилки, і кожна лінія має 120-хвилинний резервний тайм-аут, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail лінії використовують жорсткіші обмеження для окремих ліній. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні лінії планувальника, зокрема release-only lanes на кшталт `install-e2e` і розділені bundled update lanes на кшталт `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб agents могли відтворити одну невдалу лінію. Багаторазовий live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття package, image kind, live image, lane і credentials потрібне, а потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact із `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли плану потрібні package-installed lanes; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість перебудови. Завантаження Docker image повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий registry/cache stream швидко повторювався замість того, щоб споживати більшу частину критичного шляху CI. Workflow `Package Acceptance` є високорівневим package gate: він визначає кандидата з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або артефакту попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у багаторазовий Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна логіка acceptance могла перевіряти старіші довірені commits без checkout старого workflow code. Release checks запускають власну дельту Package Acceptance для цільового ref: сумісність bundled-channel, offline plugin fixtures і Telegram package QA проти визначеного tarball. Docker suite release-path запускає менші розбиті jobs із `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний image kind і виконував кілька ліній через той самий зважений планувальник (`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|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|bundled-channels`). OpenWebUI включається в `plugins-runtime-services`, коли повне release-path-покриття його запитує, і зберігає окремий chunk `openwebui` лише для dispatches, що стосуються тільки OpenWebUI. Застарілі агреговані назви chunks `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` усе ще працюють для ручних повторних запусків, але release workflow використовує розділені chunks, щоб installer E2E і перевірки install/uninstall bundled plugin не домінували критичний шлях. Alias лінії `install-e2e` залишається агрегованим alias для ручного повторного запуску обох provider installer lanes. Chunk `bundled-channels` запускає розділені лінії `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну all-in-one лінію `bundled-channel-deps`. Кожен chunk завантажує `.artifacts/docker-tests/` з logs ліній, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує debugging невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана лінія є live Docker lane, цільовий job локально збирає live-test image для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли такі значення існують, тож невдала лінія може повторно використати точний package і images з невдалого запуску. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts із GitHub run і вивести комбіновані/цільові команди повторного запуску для кожної лінії; використовуйте `pnpm test:docker:timings ` для підсумків slow-lane і phase critical-path. Запланований live/E2E workflow щодня запускає повний release-path Docker suite. Матриця bundled update розділена за ціллю оновлення, щоб повторні npm update і doctor repair passes могли шардитися з іншими bundled checks. -Поточні Docker-фрагменти релізу: `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`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` лишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` лишаються агрегованими псевдонімами плагінів/середовища виконання, але workflow релізу використовує розділені фрагменти, щоб smoke-перевірки каналів, цілі оновлення, перевірки середовища виконання плагінів і проходи встановлення/видалення вбудованих плагінів могли виконуватися паралельно. Цільові dispatch-запуски `docker_lanes` також розділяють кілька вибраних ланів на паралельні jobs після одного спільного кроку підготовки пакета/образу, а лани оновлення вбудованих каналів повторюють спробу один раз у разі тимчасових мережевих збоїв npm. +Поточні 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-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`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований chunk `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими alias для plugin/runtime, але release workflow використовує розділені chunks, щоб channel smokes, update targets, plugin runtime checks і перевірки install/uninstall bundled plugin могли виконуватися паралельно. Цільові dispatches `docker_lanes` також розділяють кілька вибраних ліній на паралельні jobs після одного спільного етапу підготовки package/image, а bundled-channel update lanes повторюють спробу один раз для тимчасових npm network failures. -Локальна логіка змінених ланів міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope CI-платформи: зміни production-коду ядра запускають typecheck production-коду ядра й тестів ядра плюс lint/guards ядра, зміни лише тестів ядра запускають лише typecheck тестів ядра плюс lint ядра, зміни production-коду розширень запускають typecheck production-коду розширень і тестів розширень плюс lint розширень, а зміни лише тестів розширень запускають typecheck тестів розширень плюс lint розширень. Зміни Public Plugin SDK або контрактів плагінів розширюються до typecheck розширень, оскільки розширення залежать від цих контрактів ядра, але Vitest-проходи розширень є явною тестовою роботою. Версійні bump-и лише release-метаданих запускають цільові перевірки версії/config/root-dependency. Невідомі зміни root/config fail safe до всіх check-ланів. -Локальна маршрутизація змінених тестів міститься в `scripts/test-projects.test-support.mjs` і -навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, -зміни source віддають перевагу явним mappings, потім sibling-тестам та import-graph -dependents. Спільна delivery-конфігурація group-room є одним з явних mappings: -зміни до конфігурації видимих відповідей групи, режиму доставки source-відповідей або -system prompt message-tool проходять через core reply tests плюс регресії доставки Discord і -Slack, щоб зміна спільного default падала ще до першого PR -push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна +Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широка область платформ CI: production-зміни core запускають core prod і core test typecheck плюс core lint/guards, зміни core лише в тестах запускають тільки core test typecheck плюс core lint, production-зміни extension запускають extension prod і extension test typecheck плюс extension lint, а зміни extension лише в тестах запускають extension test typecheck плюс extension lint. Зміни Public Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts, але Vitest extension sweeps є явною тестовою роботою. Version bumps лише release metadata запускають цільові version/config/root-dependency checks. Невідомі зміни root/config безпечно переходять до всіх check lanes. +Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і +навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, +редагування вихідного коду надають перевагу явним mappings, потім sibling tests та import-graph +dependents. Спільна конфігурація доставки group-room є одним із явних mappings: +зміни group visible-reply config, source reply delivery mode або +message-tool system prompt проходять через core reply tests плюс Discord і +Slack delivery regressions, щоб зміна спільного default падала до першого +push PR. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий mapped set не є надійним proxy. -Для Testbox-валидації запускайте з кореня репозиторію й віддавайте перевагу свіжому прогрітому box для -широкого proof. Перш ніж витрачати повільний gate на box, який було повторно використано, термін якого сплив або -який щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині -box. Sanity-перевірка швидко падає, коли зникли потрібні root-файли, як-от -`pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 -відстежуваних видалень. Зазвичай це означає, що remote sync state не є надійною -копією PR. Зупиніть цей box і прогрійте свіжий замість налагодження -збою product test. Для навмисних PR з великими видаленнями встановіть +Для валідації Testbox запускайте з кореня репозиторію й надавайте перевагу свіжому прогрітому боксу для +широкого підтвердження. Перед тим як витрачати повільний gate на бокс, який повторно використали, термін дії якого сплив або +який щойно повідомив про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині +бокса. Sanity-перевірка швидко падає, коли потрібні кореневі файли, як-от +`pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 +відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною +копією PR. Зупиніть цей бокс і прогрійте свіжий замість налагодження +збою продуктового тесту. Для PR з навмисними великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity-запуску. `pnpm -testbox:run` також завершує локальний виклик Blacksmith CLI, який лишається у -sync phase понад п’ять хвилин без post-sync output. Встановіть -`OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше -значення в мілісекундах для незвично великих локальних diffs. +testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у +фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Встановіть +`OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей запобіжник, або використайте більше +значення в мілісекундах для незвично великих локальних diff. -Ручні CI dispatch-запуски виконують `checks-node-compat-node22` як широке coverage сумісності. Android є opt-in для standalone manual CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` є дорожчим product/package coverage, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull requests, push-и в `main` і standalone manual CI dispatch-запуски тримають цей suite вимкненим. +Ручні CI-запуски виконують `checks-node-compat-node22` як широке покриття сумісності. Android є опційним для окремого ручного CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` має дорожче покриття продукту/пакетів, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і окремі ручні CI-запуски тримають цей набір вимкненим. -Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожен job лишався малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes спарені, auto-reply запускається як чотири збалансовані workers з reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media та miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. `Plugin Prerelease` балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Широкий agents lane використовує спільний Vitest file-parallel scheduler, бо він домінований імпортом/плануванням, а не одним повільним test file. `runtime-config` запускається з infra core-runtime shard, щоб shared runtime shard не володів tail. Include-pattern shards записують timing entries із використанням CI shard name, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards конкурентно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі check names як легкі verifier jobs і водночас уникаючи двох додаткових Blacksmith workers і другої artifact-consumer queue. -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. -GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або `main` ref. Вважайте це CI-шумом, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже superseded. -Автоматичний CI concurrency key версійований (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. +Найповільніші родини тестів Node розділено або збалансовано, щоб кожна job залишалася малою без надмірного резервування раннерів: контракти каналів виконуються як три зважені шарди, малі core unit lanes поєднані парами, auto-reply запускається як чотири збалансовані worker-и з піддеревом reply, розділеним на шарди 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. `Plugin Prerelease` балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу й більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Широка agents lane використовує спільний Vitest file-parallel scheduler, бо вона обмежена імпортами/плануванням, а не одним повільним тестовим файлом. `runtime-config` виконується з infra core-runtime shard, щоб shared runtime shard не володів хвостом. Include-pattern shards записують timing entries з назвою CI shard, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілу config від відфільтрованого 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/` вже зібрані, зберігаючи свої старі check names як легкі verifier jobs і водночас уникаючи двох додаткових Blacksmith workers та другої artifact-consumer queue. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює цей flavor з SMS/call-log BuildConfig flags, уникаючи дублювання debug APK packaging job під час кожного Android-relevant push. +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-*` і не скасовують in-progress runs. -## Runners +## Ранери -| Runner | Jobs | +| Ранер | Jobs | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, швидкі security jobs та aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards крім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, нижчі за вагою extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards крім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lower-weight extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | | `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який лишається достатньо CPU-sensitive, щоб 8 vCPU коштували більше, ніж зекономили; install-smoke Docker builds, де 32-vCPU queue time коштував більше, ніж зекономив | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо CPU-sensitive, тож 8 vCPU коштували більше, ніж заощаджували; install-smoke Docker builds, де час у черзі для 32-vCPU коштував більше, ніж заощаджував | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | ## Локальні еквіваленти @@ -477,4 +460,4 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Пов’язане - [Огляд встановлення](/uk/install) -- [Канали випусків](/uk/install/development-channels) +- [Канали релізів](/uk/install/development-channels) diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index a863524c7..6ed7aee6b 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,163 +1,242 @@ --- read_when: - - Пошук визначень загальнодоступних каналів випуску - - Запуск перевірки релізу або приймального тестування пакета - - Пошук правил іменування версій і періодичності випусків -summary: Релізні лінії, контрольний список оператора, бокси валідації, іменування версій і каденція + - Пошук визначень публічних каналів випуску + - Запуск перевірки випуску або приймання пакета + - Шукаємо іменування версій і періодичність випусків +summary: Релізні лінії, контрольний список оператора, бокси валідації, іменування версій і періодичність title: Політика випусків x-i18n: - generated_at: "2026-04-29T10:40:36Z" + generated_at: "2026-04-29T11:37:38Z" model: gpt-5.5 provider: openai - source_hash: 815c4bffe7930384584533e934996592114af510ebd775fc873086d63c74203f + source_hash: bc944cc72f61226363cd6684c1b4830c518874da21bcf8127d365772275f17f7 source_path: reference/RELEASING.md workflow: 16 --- -OpenClaw має три публічні гілки релізів: +OpenClaw має три публічні канали випусків: -- stable: позначені тегами релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано -- beta: передрелізні теги, які публікуються в npm `beta` +- stable: позначені тегами випуски, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано +- beta: теги попередніх випусків, які публікуються в npm `beta` - dev: рухома вершина `main` -## Назви версій +## Іменування версій -- Версія стабільного релізу: `YYYY.M.D` +- Версія стабільного випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія коригувального стабільного релізу: `YYYY.M.D-N` +- Версія корекційного стабільного випуску: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія beta-передрелізу: `YYYY.M.D-beta.N` +- Версія попереднього beta-випуску: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не додавайте початкові нулі до місяця чи дня -- `latest` означає поточний просунутий стабільний npm-реліз +- Не додавайте початковий нуль до місяця або дня +- `latest` означає поточний просунутий стабільний npm-випуск - `beta` означає поточну ціль встановлення beta -- Стабільні та коригувальні стабільні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлитися на `latest` або пізніше просунути перевірену beta-збірку -- Кожен стабільний реліз OpenClaw постачається разом із npm-пакетом і застосунком macOS; - beta-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а - збирання/підписування/нотаризація Mac-застосунку лишаються для стабільних релізів, якщо їх явно не запитано +- Стабільні та корекційні стабільні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену beta-збірку +- Кожен стабільний випуск OpenClaw постачає npm-пакет і застосунок macOS разом; + beta-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а + збирання/підписування/нотаризація застосунку Mac зарезервовані для стабільних випусків, якщо не запитано явно -## Частота релізів +## Періодичність випусків -- Релізи рухаються спочатку через beta -- Стабільний реліз виходить лише після перевірки останньої beta -- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної - з поточного `main`, щоб перевірка релізу та виправлення не блокували нову +- Випуски рухаються спочатку через beta +- Стабільний випуск іде лише після перевірки останньої beta +- Супровідники зазвичай відгалужують випуски з гілки `release/YYYY.M.D`, створеної + з поточного `main`, щоб перевірка випуску й виправлення не блокували нову розробку в `main` -- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють - наступний тег `-beta.N` замість видалення чи повторного створення старого beta-тега -- Докладна процедура релізу, схвалення, облікові дані та нотатки з відновлення - доступні лише мейнтейнерам +- Якщо beta-тег уже було надіслано або опубліковано й він потребує виправлення, супровідники створюють + наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега +- Докладна процедура випуску, погодження, облікові дані та нотатки з відновлення + доступні лише супровідникам -## Контрольний список оператора релізу +## Контрольний список оператора випуску -Цей контрольний список є публічною формою релізного процесу. Приватні облікові дані, -підписування, нотаризація, відновлення dist-tag і подробиці екстреного відкату лишаються в -релізному runbook лише для мейнтейнерів. +Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані, +підписування, нотаризація, відновлення dist-tag і подробиці екстреного відкату залишаються в +інструкції з випуску лише для супровідників. 1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано, - і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити з нього гілку. -2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою - `/changelog`, залиште записи орієнтованими на користувачів, закомітьте їх, надішліть і виконайте rebase/pull + і підтвердьте, що поточний CI `main` достатньо зелений, щоб відгалужуватися від нього. +2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою + `/changelog`, залиште записи орієнтованими на користувача, закомітьте це, надішліть зміни й виконайте rebase/pull ще раз перед створенням гілки. -3. Перегляньте записи сумісності релізу в +3. Перегляньте записи сумісності випуску в `src/plugins/compat/registry.ts` і `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену - сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її + сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її навмисно збережено. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну релізну роботу +4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском безпосередньо в `main`. -5. Оновіть кожне потрібне місце з версією для запланованого тега, потім запустіть +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` для - релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу - для чотирьох великих релізних тестових середовищ: Vitest, Docker, QA Lab і Package. -8. Якщо перевірка не пройшла, виправте в релізній гілці й повторно запустіть найменший невдалий - файл, гілку, завдання workflow, профіль пакета, провайдера або allowlist моделей, що - доводить виправлення. Повторно запускайте повну umbrella-перевірку лише тоді, коли змінена поверхня робить + гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу + для чотирьох великих тестових боксів випуску: Vitest, Docker, QA-лабораторія і Package. +8. Якщо валідація не пройшла, виправте в гілці випуску й повторно запустіть найменший файл, + канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що + доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить попередні докази застарілими. 9. Для beta позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть - post-publish package acceptance проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` + післяпублікаційне приймання пакета для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або `openclaw@beta`. Якщо надіслана або опублікована beta потребує виправлення, створіть наступний `-beta.N`; не видаляйте й не переписуйте стару beta. -10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate має - потрібні докази перевірки. Стабільна npm-публікація повторно використовує успішний - артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного релізу macOS +10. Для стабільного випуску продовжуйте лише після того, як перевірена beta або кандидат у випуск матиме + необхідні докази валідації. Публікація стабільного npm повторно використовує успішний + артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного macOS-випуску також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. -11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний - published-npm Telegram E2E, коли потрібен post-publish доказ каналу, - просування dist-tag за потреби, нотатки GitHub release/prerelease з - повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу. +11. Після публікації запустіть npm-перевірник після публікації, необов’язковий автономний + опублікований-npm Telegram E2E, коли потрібен доказ каналу після публікації, + просування dist-tag за потреби, нотатки GitHub-випуску/попереднього випуску з + повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску. -## Попередня перевірка релізу +## Попередня перевірка випуску -- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check` -- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпортів і архітектурних меж були зеленими поза швидшим локальним шлюзом -- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані релізні артефакти `dist/*` і бандл Control UI існували для кроку валідації пакування -- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб запустити всі передрелізні test boxes з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний `CI` і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета, коли також потрібно виконати post-publish Telegram E2E. Надавайте `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що валідація відповідає опублікованому npm-пакету, не примушуючи запускати Telegram E2E. Приклад: +- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався + покритим поза швидшим локальним бар’єром `pnpm check` +- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів + імпортів і меж архітектури були зеленими поза швидшим локальним бар’єром +- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані + релізні артефакти `dist/*` і бандл Control UI існували для кроку + валідації пакування +- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб + запустити всі передрелізні тестові boxes з однієї точки входу. Він приймає гілку, + тег або повний SHA коміту, запускає ручний `CI` і запускає + `OpenClaw Release Checks` для install smoke, package acceptance, Docker + release-path suite’ів, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram + lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета + і коли post-publish Telegram E2E також має виконатися. Надавайте + `evidence_package_spec`, коли приватний evidence-звіт має довести, що + валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. + Приклад: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ із побічного каналу для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub Actions. Workflow визначає кандидата як `package-under-test`, повторно використовує планувальник Docker E2E релізу для цього tarball і може запускати Telegram QA для того самого tarball з `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. +- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження + для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для + `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, + щоб упакувати довірену гілку/тег/SHA `package_ref` з поточним + harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим + SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском + GitHub Actions. Workflow розв’язує кандидата до + `package-under-test`, повторно використовує Docker E2E release scheduler для цього + tarball і може запускати Telegram QA для того самого tarball з + `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Приклад: `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 telegram_mode=mock-openai` Поширені профілі: - - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації - - `package`: lanes пакета/оновлення/Plugin, нативні для артефакта, без OpenWebUI або live ClawHub - - `product`: профіль package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI - - `full`: фрагменти Docker release-path з OpenWebUI + - `smoke`: lanes інсталяції/channel/agent, Gateway-мережі та перезавантаження config + - `package`: package/update/plugin lanes, прив’язані до артефакта, без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP channels, очищення cron/subagent, + OpenAI web search і OpenWebUI + - `full`: Docker release-path chunks з 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, перевірки документації, Python skills, Windows, macOS, Android і lanes Control UI i18n. +- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне + CI-покриття для релізного кандидата. Ручні CI dispatch обходять changed + scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel + contracts, сумісність Node 22, `check`, `check-additional`, build smoke, + перевірки docs, Python Skills, Windows, macOS, Android і Control UI i18n + lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним тегованим релізом -- Релізні перевірки тепер запускаються в окремому ручному workflow: +- Запустіть `pnpm qa:otel:smoke`, коли валідуєте релізну телеметрію. Він проганяє + QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace + span, обмежені атрибути та редагування content/identifier без потреби в + Opik, Langfuse або іншому зовнішньому collector. +- Запускайте `pnpm release:check` перед кожним релізом із тегом +- Release checks тепер виконуються в окремому ручному workflow: `OpenClaw Release Checks` -- `OpenClaw Release Checks` також запускає mock parity gate QA Lab плюс швидкий 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 transport, media та E2EE паралельно. -- Cross-OS runtime-валідація встановлення й оновлення є частиною публічних `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають reusable workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Цей поділ навмисний: реальний npm release path має залишатися коротким, детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у власній lane, щоб не затримувати й не блокувати публікацію -- Релізні перевірки із секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і секрети залишалися контрольованими -- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо визначений коміт досяжний з гілки OpenClaw або релізного тегу -- validation-only preflight `OpenClaw NPM Release` також приймає поточний повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу -- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальну публікацію -- У режимі SHA workflow синтезує `v` лише для перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу -- Обидва workflow залишають реальний шлях публікації й просування на GitHub-hosted runners, тоді як немутаційний шлях валідації може використовувати більші Blacksmith Linux runners +- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий + live Matrix profile і Telegram QA lane перед схваленням релізу. Live + lanes використовують середовище `qa-live-shared`; Telegram також використовує Convex CI + credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з + `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний Matrix + transport, media і E2EE inventory паралельно. +- Cross-OS валідація інсталяції та оновлення runtime є частиною публічних + `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають + reusable workflow + `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` +- Це розділення навмисне: тримайте реальний npm release path коротким, + детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у власному + lane, щоб вони не затримували і не блокували publish +- Release checks із секретами слід запускати через `Full Release +Validation` або з workflow ref `main`/release, щоб логіка workflow і + secrets залишалися контрольованими +- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо + розв’язаний коміт доступний з гілки OpenClaw або релізного тегу +- Validation-only preflight `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту гілки workflow без потреби в запушеному тегу +- Цей SHA path призначений лише для валідації і не може бути просунутий у реальний publish +- У SHA mode workflow синтезує `v` лише для + перевірки package metadata; реальний publish все ще потребує справжнього release tag +- Обидва workflows тримають реальний publish і promotion path на GitHub-hosted + runners, тоді як немутувальний validation path може використовувати більші + Blacksmith Linux runners - Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` - з використанням workflow-секретів `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` -- npm release preflight більше не чекає на окрему lane релізних перевірок + використовуючи workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- npm release preflight більше не чекає на окремий release checks lane - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний beta/correction тег) перед схваленням + (або відповідний beta/correction tag) перед схваленням - Після npm publish запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction версію), щоб перевірити опублікований шлях встановлення з registry у свіжому тимчасовому префіксі + (або відповідну beta/correction version), щоб перевірити published registry + install path у свіжому temp 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` - щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. Локальні одноразові запуски мейнтейнерів можуть опускати змінні Convex і передавати три облікові дані env `OPENCLAW_QA_TELEGRAM_*` напряму. -- Мейнтейнери можуть запустити таку саму post-publish перевірку з GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і не запускається на кожному merge. -- Релізна автоматизація мейнтейнерів тепер використовує preflight-then-promote: - - реальна npm-публікація має пройти успішний npm `preflight_run_id` - - реальна npm-публікація має запускатися з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - - стабільні npm-релізи типово використовують `beta` - - стабільна npm-публікація може явно цілитися в `latest` через workflow input - - token-based мутація npm dist-tag тепер розміщена в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` з міркувань безпеки, оскільки `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish - - публічний `macOS Release` є validation-only - - реальна приватна mac publish має пройти успішні приватні mac `preflight_run_id` і `validate_run_id` - - реальні publish paths просувають підготовлені артефакти замість повторної перебудови -- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier також перевіряє той самий шлях оновлення temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`, щоб release corrections не могли непомітно залишити старі глобальні встановлення на базовому stable payload -- npm release preflight fails closed, якщо tarball не містить і `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, щоб ми знову не відправили порожню браузерну dashboard -- Post-publish verification також перевіряє, що опубліковане встановлення з registry містить непорожні runtime-залежності bundled plugin під кореневою розкладкою `dist/*`. Реліз, який постачається з відсутніми або порожніми dependency payloads bundled plugin, не проходить postpublish verifier і не може бути просунутий до `latest`. -- `pnpm test:install:smoke` також забезпечує бюджет `unpackedSize` npm pack для candidate update tarball, щоб installer e2e виявляв випадкове роздування пакета до release publish path -- Якщо релізна робота торкнулася планування CI, timing manifests розширень або test matrices розширень, регенеруйте й перегляньте outputs matrix `plugin-prerelease-extension-shard`, якими володіє planner, з `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не описували застарілий layout CI -- Готовність стабільного macOS-релізу також включає поверхні updater: - - GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - - `appcast.xml` у `main` має вказувати на новий stable zip після publish - - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor для цієї релізної версії + щоб перевірити installed-package onboarding, налаштування Telegram і реальний Telegram E2E + проти опублікованого npm-пакета з використанням спільного leased Telegram credential + pool. Локальні одноразові maintainer-запуски можуть пропустити Convex vars і передати три + env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. +- Maintainers можуть запускати таку саму post-publish перевірку з GitHub Actions через + ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і + не запускається на кожному merge. +- Maintainer release automation тепер використовує preflight-then-promote: + - реальний npm publish має пройти успішний npm `preflight_run_id` + - реальний npm publish має бути запущений з тієї самої гілки `main` або + `release/YYYY.M.D`, що й успішний preflight run + - стабільні npm releases за замовчуванням використовують `beta` + - стабільний npm publish може явно цілитися в `latest` через workflow input + - token-based npm dist-tag mutation тепер живе в + `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` + з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як + public repo зберігає OIDC-only publish + - публічний `macOS Release` є лише validation-only + - реальний private mac publish має пройти успішні private mac + `preflight_run_id` і `validate_run_id` + - реальні publish paths просувають підготовлені артефакти замість повторного + їх rebuild +- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier + також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`, + щоб release corrections не могли непомітно залишити старіші global installs на + базовому stable payload +- npm release preflight fails closed, якщо tarball не містить і + `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, + щоб ми знову не відправили порожній browser dashboard +- Post-publish verification також перевіряє, що published registry install + містить непорожні bundled plugin runtime deps під root layout `dist/*`. + Реліз, який виходить із відсутніми або порожніми bundled plugin + dependency payloads, не проходить postpublish verifier і не може бути просунутий + до `latest`. +- `pnpm test:install:smoke` також примусово перевіряє бюджет npm pack `unpackedSize` для + candidate update tarball, щоб installer e2e ловив випадкове pack bloat + до release publish path +- Якщо релізна робота торкалася CI planning, extension timing manifests або + extension test matrices, згенеруйте заново і перегляньте planner-owned + matrix outputs `plugin-prerelease-extension-shard` з + `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не + описували застарілий CI layout +- Готовність стабільного macOS release також охоплює updater surfaces: + - GitHub release має зрештою містити packaged `.zip`, `.dmg` і `.dSYM.zip` + - `appcast.xml` на `main` має вказувати на новий stable zip після publish + - packaged app має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor + для цієї release version -## Релізні test boxes +## Релізні тестові boxes -`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну гілку, тег або повний SHA коміту як `ref`: +`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з +однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте release +branch, tag або повний commit SHA як `ref`: ```bash gh workflow run full-release-validation.yml \ @@ -169,21 +248,42 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Workflow визначає target ref, запускає ручний `CI` з `target_ref=`, запускає `OpenClaw Release Checks` і за потреби запускає автономний post-publish Telegram E2E, коли задано `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, live Matrix і live Telegram. Повний запуск є прийнятним лише тоді, коли summary `Full Release Validation` показує `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий child `npm_telegram` або успішний, або навмисно пропущений. Фінальна verifier summary містить таблиці найповільніших jobs для кожного child run, щоб release manager міг бачити поточний critical path без завантаження логів. -Child workflows запускаються з довіреного ref, який виконує `Full Release Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на старішу релізну гілку або тег. Окремого workflow-ref input для Full Release Validation немає; обирайте довірений harness, обираючи workflow run ref. +Workflow розв’язує target ref, запускає ручний `CI` з +`target_ref=`, запускає `OpenClaw Release Checks` і +опційно запускає standalone post-publish Telegram E2E, коли +`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. Повний запуск прийнятний лише тоді, коли summary `Full Release Validation` +показує `normal_ci` і `release_checks` як успішні, а будь-який optional +child `npm_telegram` або успішний, або навмисно пропущений. Фінальний +verifier summary містить таблиці slowest-job для кожного child run, щоб release +manager міг бачити поточний critical path без завантаження logs. +Child workflows запускаються з довіреного ref, який запускає `Full Release +Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на +старішу release branch або tag. Окремого workflow-ref input для Full Release Validation +немає; вибирайте довірений harness, вибираючи workflow run ref. Використовуйте `release_profile`, щоб вибрати ширину live/provider: - `minimum`: найшвидший release-critical OpenAI/core live і Docker path -- `stable`: minimum плюс стабільне покриття provider/backend для схвалення релізу -- `full`: stable плюс широке advisory покриття provider/media +- `stable`: minimum плюс stable provider/backend coverage для release approval +- `full`: stable плюс широке advisory provider/media coverage -`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити target ref як `release-package-under-test`, і повторно використовує цей артефакт як у Docker checks release-path, так і в Package Acceptance. Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок пакета. +`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз розв’язати target +ref як `release-package-under-test`, і повторно використовує цей артефакт і в +release-path Docker checks, і в Package Acceptance. Це тримає всі +package-facing boxes на тих самих байтах і уникає повторних package builds. +Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли +repo/org variable задано, інакше `openai/gpt-5.4-mini`, бо цей lane +доводить package install, onboarding, запуск Gateway і один live agent turn, +а не benchmark найповільнішої default model. Ширша live provider +matrix лишається місцем для model-specific coverage. Використовуйте ці варіанти залежно від етапу релізу: ```bash -# Валідуйте неопубліковану гілку кандидата релізу. +# Validate an unpublished release candidate branch. gh workflow run full-release-validation.yml \ --ref main \ -f ref=release/YYYY.M.D \ @@ -191,14 +291,14 @@ gh workflow run full-release-validation.yml \ -f mode=both \ -f release_profile=stable -# Валідуйте точний запушений коміт. +# Validate an exact pushed commit. gh workflow run full-release-validation.yml \ --ref main \ -f ref=<40-char-sha> \ -f provider=openai \ -f mode=both -# Після публікації beta додайте Telegram E2E для опублікованого пакета. +# After publishing a beta, add published-package Telegram E2E. gh workflow run full-release-validation.yml \ --ref main \ -f ref=release/YYYY.M.D \ @@ -210,39 +310,39 @@ gh workflow run full-release-validation.yml \ ``` Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один бокс -зазнає збою, використовуйте невдалий дочірній робочий процес, завдання, Docker-ланку, профіль пакета, постачальника -моделі або QA-ланку для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли +зазнає невдачі, використайте невдалий дочірній workflow, job, Docker lane, профіль пакета, модельного +провайдера або QA lane для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх боксів -застарілими. Фінальний перевіряльник парасольки повторно перевіряє записані id запусків дочірніх робочих процесів, -тому після успішного повторного запуску дочірнього робочого процесу повторно запустіть лише невдале -батьківське завдання `Verify full validation`. +застарілими. Фінальний перевіряльник парасольки повторно перевіряє записані ідентифікатори запусків дочірніх workflow, +тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдалий +батьківський job `Verify full validation`. Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це справжній -запуск реліз-кандидата, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` -запускає лише релізний дочірній процес плагіна, `release-checks` запускає кожен релізний +запуск release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` +запускає лише релізний дочірній plugin, `release-checks` запускає кожен релізний бокс, а вужчі релізні групи — це `install-smoke`, `cross-os`, -`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`, коли надано -окрему пакетну Telegram-ланку. +`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`, коли +надано автономний package Telegram lane. ### Vitest -Бокс Vitest — це ручний дочірній робочий процес `CI`. Ручний CI навмисно -оминає звуження за змінами та примусово запускає звичайний тестовий граф для реліз-кандидата: -Linux Node-шарди, шарди вбудованих плагінів, контракти каналів, сумісність із Node 22, -`check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, -macOS, Android і i18n Control UI. +Бокс Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно +оминає scoped перевірки змін і примусово запускає звичайний граф тестів для release +candidate: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність Node 22, +`check`, `check-additional`, build smoke, перевірки docs, Python +skills, Windows, macOS, Android і Control UI i18n. -Використовуйте цей бокс, щоб відповісти на запитання: "чи пройшло дерево вихідного коду повний звичайний набір тестів?" -Це не те саме, що продуктова валідація релізного шляху. Докази, які потрібно зберігати: +Використовуйте цей бокс, щоб відповісти на запитання «чи пройшло дерево вихідного коду повний звичайний набір тестів?» +Це не те саме, що продуктова валідація release path. Докази, які треба зберегти: -- зведення `Full Release Validation`, що показує URL запущеного `CI` +- summary `Full Release Validation`, що показує URL запущеного `CI` - зелений запуск `CI` на точному цільовому SHA -- назви невдалих або повільних шардів із завдань CI під час дослідження регресій -- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли +- назви невдалих або повільних шардів із CI jobs під час дослідження регресій +- артефакти таймінгу Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли запуск потребує аналізу продуктивності Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але -не потрібні Docker, QA Lab, live, cross-OS або пакетні бокси: +не потрібні бокси Docker, QA Lab, live, cross-OS або package: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D @@ -251,15 +351,15 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker Бокс Docker живе в `OpenClaw Release Checks` через -`openclaw-live-and-e2e-checks-reusable.yml`, а також у релізному режимі робочого процесу -`install-smoke`. Він перевіряє реліз-кандидат через пакетовані -Docker-середовища, а не лише тести на рівні вихідного коду. +`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode +workflow `install-smoke`. Він валідує release candidate через packaged +Docker-середовища, а не лише через тести рівня вихідного коду. -Релізне Docker-покриття включає: +Покриття релізного Docker включає: - повний install smoke з увімкненим повільним Bun global install smoke -- E2E-ланки репозиторію -- Docker-фрагменти релізного шляху: `core`, `package-update-openai`, +- repository E2E lanes +- release-path 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-b`, @@ -269,81 +369,81 @@ Docker-середовища, а не лише тести на рівні вих `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts` -- покриття OpenWebUI всередині фрагмента `plugins-runtime-services`, коли його запитано -- розділені ланки залежностей вбудованих каналів між channel-smoke, update-target - і фрагментами контрактів setup/runtime замість одного великого завдання для вбудованих каналів -- розділені ланки встановлення/видалення вбудованих плагінів - `bundled-plugin-install-uninstall-0` через +- покриття OpenWebUI всередині chunk `plugins-runtime-services`, коли це запитано +- розділені dependency lanes bundled-channel між channel-smoke, update-target + і setup/runtime contract chunks замість одного великого bundled-channel job +- розділені lanes встановлення/видалення bundled plugin + від `bundled-plugin-install-uninstall-0` до `bundled-plugin-install-uninstall-23` -- live/E2E-набори постачальників і Docker live-покриття моделей, коли релізні перевірки - включають live-набори +- live/E2E provider suites і Docker live model coverage, коли release checks + включають live suites -Використовуйте Docker-артефакти перед повторним запуском. Планувальник релізного шляху завантажує -`.artifacts/docker-tests/` із журналами ланок, `summary.json`, `failures.json`, -таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення -використовуйте `docker_lanes=` у багаторазовому live/E2E-робочому процесі замість -повторного запуску всіх релізних фрагментів. Згенеровані команди повторного запуску включають попередні -`package_artifact_run_id` і підготовлені вхідні дані Docker-образів, коли вони доступні, щоб -невдала ланка могла повторно використати той самий tarball і GHCR-образи. +Використовуйте Docker-артефакти перед повторним запуском. Release-path scheduler завантажує +`.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`, +phase timings, JSON плану scheduler і командами повторного запуску. Для сфокусованого відновлення +використовуйте `docker_lanes=` у reusable live/E2E workflow замість +повторного запуску всіх релізних chunks. Згенеровані команди повторного запуску включають попередні +`package_artifact_run_id` і підготовлені inputs Docker image, коли вони доступні, щоб +невдалий lane міг повторно використати той самий tarball і GHCR images. ### QA Lab -Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це релізний гейт -агентної поведінки та рівня каналів, окремий від механіки пакетів Vitest і Docker. +Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це agentic +behavior і релізний gate рівня каналів, окремий від Vitest і Docker +package mechanics. -Релізне покриття QA Lab включає: +Покриття релізного QA Lab включає: -- mock parity gate, що порівнює кандидатну ланку OpenAI з базовою лінією Opus 4.6 +- mock parity gate, що порівнює candidate lane OpenAI з baseline Opus 4.6 за допомогою agentic parity pack -- швидкий live Matrix QA-профіль із використанням середовища `qa-live-shared` -- live Telegram QA-ланку з використанням оренд облікових даних Convex CI +- швидкий live Matrix QA profile з використанням середовища `qa-live-shared` +- live Telegram QA lane з використанням Convex CI credential leases - `pnpm qa:otel:smoke`, коли релізній телеметрії потрібне явне локальне підтвердження -Використовуйте цей бокс, щоб відповісти на запитання: "чи поводиться реліз правильно в QA-сценаріях і -live-потоках каналів?" Зберігайте URL артефактів для ланок parity, Matrix і Telegram -під час схвалення релізу. Повне Matrix-покриття залишається доступним як -ручний шардований запуск QA-Lab, а не типова релізно-критична ланка. +Використовуйте цей бокс, щоб відповісти на запитання «чи реліз поводиться правильно у QA-сценаріях і +live channel flows?» Зберігайте URL артефактів для lanes parity, Matrix і Telegram +під час затвердження релізу. Повне покриття Matrix залишається доступним як +ручний sharded QA-Lab run, а не стандартний release-critical lane. ### Пакет -Бокс Package — це гейт інстальованого продукту. Він спирається на -`Package Acceptance` і резолвер -`scripts/resolve-openclaw-package-candidate.mjs`. Резолвер нормалізує -кандидат у tarball `package-under-test`, який споживає Docker E2E, перевіряє -інвентар пакета, записує версію пакета та SHA-256 і тримає ref обв'язки -робочого процесу окремо від ref вихідного коду пакета. +Бокс Package — це gate інстальованого продукту. Він підтримується +`Package Acceptance` і resolver +`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує +candidate у tarball `package-under-test`, який споживає Docker E2E, валідує +package inventory, записує версію пакета та SHA-256 і тримає +ref workflow harness окремо від ref вихідного коду пакета. -Підтримувані джерела кандидатів: +Підтримувані джерела candidate: -- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна релізна - версія OpenClaw -- `source=ref`: запакувати довірену гілку `package_ref`, тег або повний commit SHA - з вибраною обв'язкою `workflow_ref` -- `source=url`: завантажити HTTPS `.tgz` з обов'язковим `package_sha256` -- `source=artifact`: повторно використати `.tgz`, завантажений іншим запуском GitHub Actions +- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw +- `source=ref`: пакує довірену `package_ref` branch, tag або повний commit SHA + з вибраним `workflow_ref` harness +- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256` +- `source=artifact`: повторно використовує `.tgz`, завантажений іншим запуском GitHub Actions `OpenClaw Release Checks` запускає Package Acceptance із `source=ref`, `package_ref=`, `suite_profile=custom`, `docker_lanes=bundled-channel-deps-compat plugins-offline` і -`telegram_mode=mock-openai`. Docker-фрагменти релізного шляху покривають -перетин ланок install, update і plugin-update; Package Acceptance зберігає -артефактно-нативну сумісність вбудованих каналів, офлайн-фікстури плагінів і Telegram -package QA щодо того самого розв'язаного tarball. Це GitHub-нативна -заміна більшої частини покриття package/update, яке раніше вимагало -Parallels. Cross-OS release checks усе ще важливі для OS-специфічного onboarding, -інсталятора та поведінки платформи, але продуктова валідація package/update має -віддавати перевагу Package Acceptance. +`telegram_mode=mock-openai`. Release-path Docker chunks покривають +перекривні lanes install, update і plugin-update; Package Acceptance зберігає +artifact-native bundled-channel compat, offline plugin fixtures і Telegram +package QA щодо того самого resolved tarball. Це GitHub-native +заміна більшості покриття package/update, яке раніше вимагало +Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding, +installer і platform behavior, але продуктова валідація package/update має +надавати перевагу Package Acceptance. -Пом'якшення legacy package-acceptance навмисно обмежене в часі. Пакети до -`2026.4.25` включно можуть використовувати шлях сумісності для прогалин метаданих, уже опублікованих -у npm: приватні QA-записи інвентарю, відсутні в tarball, відсутній -`gateway install --wrapper`, відсутні patch-файли у git-фікстурі, отриманій із tarball, -відсутній збережений `update.channel`, legacy-розташування install-record плагінів, -відсутня сталість marketplace install-record і міграція метаданих config -під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати -про локальні файли штампу метаданих збірки, які вже були відвантажені. Пізніші пакети -мають відповідати сучасним контрактам пакета; ті самі прогалини провалюють релізну -валідацію. +Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до +`2026.4.25` включно можуть використовувати compatibility path для прогалин metadata, уже опублікованих +до 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, які вже були shipped. Пізніші пакети +мають відповідати сучасним package contracts; ті самі прогалини провалюють release +validation. Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується фактичного інстальованого пакета: @@ -357,86 +457,83 @@ gh workflow run package-acceptance.yml \ -f suite_profile=product ``` -Поширені профілі пакета: +Поширені профілі package: -- `smoke`: швидкі ланки встановлення пакета/каналу/агента, gateway-мережі та - перезавантаження config -- `package`: контракти install/update/plugin package без live ClawHub; це типовий варіант release-check -- `product`: `package` плюс MCP-канали, cron/очищення subagent, OpenAI web +- `smoke`: швидкі lanes package install/channel/agent, gateway network і config + reload +- `package`: контракти install/update/plugin package без live ClawHub; це стандарт release-check +- `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web search і OpenWebUI -- `full`: Docker-фрагменти релізного шляху з OpenWebUI +- `full`: Docker release-path chunks з OpenWebUI - `custom`: точний список `docker_lanes` для сфокусованих повторних запусків -Для package-candidate Telegram-підтвердження увімкніть `telegram_mode=mock-openai` або -`telegram_mode=live-frontier` у Package Acceptance. Робочий процес передає -розв'язаний tarball `package-under-test` у Telegram-ланку; окремий -Telegram-робочий процес і далі приймає опубліковану npm-специфікацію для post-publish-перевірок. +Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або +`telegram_mode=live-frontier` у Package Acceptance. Workflow передає +resolved tarball `package-under-test` до Telegram lane; автономний +Telegram workflow усе ще приймає опублікований npm spec для post-publish checks. -## Вхідні дані робочого процесу NPM +## NPM workflow inputs -`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані: +`OpenClaw NPM Release` приймає ці operator-controlled inputs: -- `tag`: обов'язковий релізний тег, як-от `v2026.4.2`, `v2026.4.2-1` або - `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний commit SHA гілки робочого процесу для preflight лише з валідацією -- `preflight_only`: `true` лише для validation/build/package, `false` для - справжнього шляху публікації -- `preflight_run_id`: обов'язковий на справжньому шляху публікації, щоб робочий процес повторно використовував - підготовлений tarball з успішного preflight-запуску -- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типово `beta` +- `tag`: обов’язковий release tag, наприклад `v2026.4.2`, `v2026.4.2-1` або + `v2026.4.2-beta.1`; коли `preflight_only=true`, він також може бути поточним + повним 40-символьним commit SHA workflow branch для 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` приймає такі керовані оператором вхідні дані: +`OpenClaw Release Checks` приймає ці operator-controlled inputs: -- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки із секретами - вимагають, щоб розв'язаний коміт був досяжним із гілки OpenClaw або - релізного тегу. +- `ref`: branch, tag або повний commit SHA для валідації. Secret-bearing checks + вимагають, щоб resolved commit був reachable з OpenClaw branch або + release tag. Правила: -- Стабільні та корекційні теги можуть публікуватися або в `beta`, або в `latest` -- Beta prerelease-теги можуть публікуватися лише в `beta` -- Для `OpenClaw NPM Release` вхідний повний commit SHA дозволений лише коли +- Stable і correction tags можуть публікуватися або до `beta`, або до `latest` +- Beta prerelease tags можуть публікуватися лише до `beta` +- Для `OpenClaw NPM Release` input повного commit SHA дозволено лише коли `preflight_only=true` - `OpenClaw Release Checks` і `Full Release Validation` завжди - лише валідаційні -- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; - робочий процес перевіряє ці метадані перед продовженням публікації + validation-only +- Справжній publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; + workflow перевіряє, що metadata перед publish продовжує відповідати ## Послідовність стабільного npm-релізу Під час випуску стабільного npm-релізу: -1. Запустіть `OpenClaw NPM Release` із `preflight_only=true` - - До створення тегу можна використати поточний повний commit SHA гілки робочого процесу - для валідаційного dry run preflight-робочого процесу -2. Виберіть `npm_dist_tag=beta` для звичайного beta-first-потоку або `latest` лише - тоді, коли ви навмисно хочете прямої стабільної публікації -3. Запустіть `Full Release Validation` на релізній гілці, релізному тегу або повному - commit SHA, коли потрібне звичайне CI-покриття плюс live prompt cache, Docker, QA Lab, - Matrix і Telegram з одного ручного робочого процесу -4. Якщо вам навмисно потрібен лише детермінований звичайний тестовий граф, запустіть - ручний робочий процес `CI` на релізному ref +1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` + - До створення tag можна використовувати поточний повний workflow-branch commit + SHA для validation-only dry run preflight workflow +2. Виберіть `npm_dist_tag=beta` для звичайного beta-first flow або `latest` лише + коли ви навмисно хочете direct stable publish +3. Запустіть `Full Release Validation` на release branch, release tag або повному + commit SHA, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab, + Matrix і Telegram coverage з одного ручного workflow +4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, запустіть + ручний workflow `CI` на release ref натомість 5. Збережіть успішний `preflight_run_id` 6. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id` -7. Якщо реліз потрапив у `beta`, використовуйте приватний - робочий процес `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, +7. Якщо реліз потрапив до `beta`, використайте приватний + workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, щоб просунути цю стабільну версію з `beta` до `latest` -8. Якщо реліз навмисно опубліковано прямо в `latest` і `beta` - має негайно вказувати на ту саму стабільну збірку, використовуйте той самий приватний - робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій - self-healing-синхронізації перемістити `beta` пізніше +8. Якщо реліз навмисно опубліковано напряму до `latest`, а `beta` + має негайно вказувати на той самий stable build, використайте той самий приватний + workflow, щоб спрямувати обидва dist-tags на stable version, або дозвольте його scheduled + self-healing sync перемістити `beta` пізніше -Мутація dist-tag живе у приватному репозиторії з міркувань безпеки, бо вона все ще -потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. +Мутація dist-tag живе в приватному repo з міркувань безпеки, бо вона все ще +потребує `NPM_TOKEN`, тоді як public repo зберігає OIDC-only publish. -Це зберігає і шлях прямої публікації, і шлях beta-first-просування +Це зберігає і direct publish path, і beta-first promotion path задокументованими та видимими для оператора. -Якщо мейнтейнер мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password -CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op` -напряму з основної оболонки агента; утримання цього всередині tmux робить prompts, -alerts і обробку OTP спостережуваними та запобігає повторним host alerts. +Якщо супровіднику доводиться повертатися до локальної автентифікації npm, виконуйте будь-які команди CLI 1Password (`op`) лише всередині окремого сеансу tmux. Не викликайте `op` безпосередньо з основної оболонки агента; утримання цього всередині tmux робить запити, сповіщення й обробку OTP спостережуваними та запобігає повторним сповіщенням хоста. ## Публічні посилання @@ -450,10 +547,10 @@ alerts і обробку OTP спостережуваними та запобі - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Супровідники використовують приватну документацію до релізів у +Супровідники використовують приватну документацію щодо випусків у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) -як фактичний регламент виконання. +як фактичний покроковий регламент. ## Пов’язане -- [Канали релізів](/uk/install/development-channels) +- [Канали випусків](/uk/install/development-channels)