chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
5b30b82ce7
commit
7aeafc9789
358
docs/uk/ci.md
358
docs/uk/ci.md
@ -1,75 +1,75 @@
|
||||
---
|
||||
read_when:
|
||||
- Потрібно зрозуміти, чому завдання CI запустилося або не запустилося
|
||||
- Ви діагностуєте перевірку GitHub Actions, що завершується з помилкою
|
||||
- Вам потрібно зрозуміти, чому завдання CI було або не було запущене
|
||||
- Ви налагоджуєте перевірку GitHub Actions, яка не проходить
|
||||
- Ви координуєте запуск або повторний запуск валідації релізу
|
||||
summary: Граф завдань CI, гейти області, релізні парасольки та локальні еквіваленти команд
|
||||
title: Конвеєр CI
|
||||
summary: Граф завдань CI, гейти області дії, релізні парасолькові перевірки та локальні еквіваленти команд
|
||||
title: CI-конвеєр
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T05:58:46Z"
|
||||
generated_at: "2026-04-30T06:10:05Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: a606991e83c50e82c1e0f8f96fd582fa1c6cbd0b999af4920f1e0af66d54d944
|
||||
source_hash: e137eff9234d8a6beb559c5367de0c75f42b892dd69148e86feb7d68c49bf437
|
||||
source_path: ci.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw CI запускається при кожному push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає витратніші напрями, коли зміни стосуються лише непов’язаних ділянок. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний граф для release candidate та широкої валідації. Напрями Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізу міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch.
|
||||
OpenClaw CI запускається для кожного push у `main` і кожного pull request. Job `preflight` класифікує diff і вимикає витратні lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне scoped-виконання та розгортають повний graph для release candidates і широкої перевірки. Android lanes залишаються opt-in через `include_android`. Покриття Plugin лише для release міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
|
||||
|
||||
## Огляд pipeline
|
||||
## Огляд Pipeline
|
||||
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- |
|
||||
| `preflight` | Виявляє зміни лише в документації, змінені scope, змінені extensions і будує CI manifest | Завжди для non-draft push і PR |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR |
|
||||
| `security-dependency-audit` | Production-аудит lockfile без dependencies на основі npm advisories | Завжди для non-draft push і PR |
|
||||
| `security-fast` | Обов’язковий aggregate для швидких security-завдань | Завжди для non-draft push і PR |
|
||||
| `check-dependencies` | Production-прохід Knip лише для dependencies плюс guard allowlist невикористаних файлів | Node-релевантні зміни |
|
||||
| `build-artifacts` | Збирає `dist/`, Control UI, перевірки built-artifact і перевикористовувані downstream artifacts | Node-релевантні зміни |
|
||||
| `checks-fast-core` | Швидкі Linux-напрями коректності, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни |
|
||||
| `checks-fast-contracts-channels` | Sharded-перевірки channel contract зі стабільним aggregate check result | Node-релевантні зміни |
|
||||
| `checks-node-core-test` | Shards тестів Core Node, без channel, bundled, contract і extension напрямів | Node-релевантні зміни |
|
||||
| `check` | Sharded-еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни |
|
||||
| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-релевантні зміни |
|
||||
| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-релевантні зміни |
|
||||
| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни |
|
||||
| `checks-node-compat-node22` | Сумісність із Node 22: build і smoke lane | Ручний CI dispatch для релізів |
|
||||
| `check-docs` | Форматування документації, lint і перевірки broken links | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для skills на Python | Зміни, релевантні Python skills |
|
||||
| `checks-windows` | Специфічні для Windows process/path tests плюс регресії shared runtime import specifier | Windows-релевантні зміни |
|
||||
| `macos-node` | macOS TypeScript test lane із використанням спільних built artifacts | macOS-релевантні зміни |
|
||||
| `macos-swift` | Swift lint, build і tests для застосунку macOS | macOS-релевантні зміни |
|
||||
| `android` | Android unit tests для обох flavors плюс одна збірка debug APK | Android-релевантні зміни |
|
||||
| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після trusted activity | Успішний Main CI або manual dispatch |
|
||||
| Job | Призначення | Коли запускається |
|
||||
| -------------------------------- | --------------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | Виявляє docs-only зміни, змінені scopes, змінені extensions і будує CI manifest | Завжди для non-draft push і PR |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR |
|
||||
| `security-dependency-audit` | Production lockfile audit без залежностей щодо npm advisories | Завжди для non-draft push і PR |
|
||||
| `security-fast` | Обов’язковий aggregate для швидких security jobs | Завжди для non-draft push і PR |
|
||||
| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist невикористаних файлів | Node-релевантні зміни |
|
||||
| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built artifacts і reusable downstream artifacts | Node-релевантні зміни |
|
||||
| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни |
|
||||
| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-релевантні зміни |
|
||||
| `checks-node-core-test` | Core Node test shards, крім channel, bundled, contract і extension lanes | Node-релевантні зміни |
|
||||
| `check` | Sharded еквівалент головного local gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни |
|
||||
| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-релевантні зміни |
|
||||
| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-релевантні зміни |
|
||||
| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни |
|
||||
| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Ручний CI dispatch для releases |
|
||||
| `check-docs` | Docs formatting, lint і перевірки broken links | Змінено docs |
|
||||
| `skills-python` | Ruff + pytest для Python-backed skills | Python-skill-релевантні зміни |
|
||||
| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Windows-релевантні зміни |
|
||||
| `macos-node` | macOS TypeScript test lane з використанням shared built artifacts | macOS-релевантні зміни |
|
||||
| `macos-swift` | Swift lint, build і tests для macOS app | macOS-релевантні зміни |
|
||||
| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-релевантні зміни |
|
||||
| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після trusted activity | Успіх Main CI або ручний dispatch |
|
||||
|
||||
## Порядок fail-fast
|
||||
|
||||
1. `preflight` вирішує, які напрями взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не очікуючи важчих artifact і platform matrix jobs.
|
||||
3. `build-artifacts` перекривається зі швидкими Linux-напрямами, щоб downstream consumers могли стартувати одразу, щойно спільний build буде готовий.
|
||||
4. Після цього розгортаються важчі platform і runtime напрями: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
1. `preflight` вирішує, які 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 могли стартувати одразу після готовності shared build.
|
||||
4. Важчі platform і runtime lanes розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
|
||||
GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI-шумом, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний CI concurrency key має версію (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
|
||||
GitHub може позначати витіснені jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI noise, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють звичайні shard failures, але не стають у чергу після того, як весь workflow уже був витіснений. Automatic CI concurrency key версіонований (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
|
||||
|
||||
## Scope і routing
|
||||
|
||||
Scope logic міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася.
|
||||
Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася.
|
||||
|
||||
- **Редагування CI workflow** перевіряють Node CI graph плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source.
|
||||
- **Редагування лише CI routing, вибрані дешеві 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 і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму.
|
||||
- **Windows Node checks** scoped до специфічних для Windows process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes.
|
||||
- **Редагування CI workflow** перевіряють Node CI graph плюс workflow linting, але самі собою не форсують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
|
||||
- **CI routing-only edits, selected cheap core-test fixture edits і narrow plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і один task `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму.
|
||||
- **Windows Node checks** scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, що виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes.
|
||||
|
||||
Найповільніші сімейства Node tests розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes поєднані в пари, auto-reply запускається як чотири збалансовані workers (із розділенням reply subtree на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізняти цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
|
||||
Найповільніші сімейства Node tests розділено або збалансовано, щоб кожен job залишався малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, small core unit lanes об’єднані парами, auto-reply запускається як чотири balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілено між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із назвою CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі independent guards concurrently в одному job. Gateway watch, channel tests і core support-boundary shard запускаються concurrently всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` вже зібрані.
|
||||
|
||||
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з BuildConfig flags для SMS/call-log, уникаючи дублювання debug APK packaging job для кожного Android-релевантного push.
|
||||
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, уникаючи duplicate debug APK packaging job для кожного Android-relevant push.
|
||||
|
||||
Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production-прохід Knip лише для dependencies, закріплений на latest Knip version, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
|
||||
Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до latest Knip version, із вимкненим pnpm minimum release age для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює Knip production unused-file findings із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий нерецензований unused file або залишає stale allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
|
||||
|
||||
## Manual dispatches
|
||||
## Ручні dispatches
|
||||
|
||||
Manual CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожен scoped lane, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі manual CI dispatches запускають Android лише з `include_android=true`; full release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний extension batch sweep і plugin prerelease Docker lanes вилучені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatches окремий workflow `Plugin Prerelease` з увімкненим release-validation gate.
|
||||
Ручні CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожен non-Android scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 compatibility, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Standalone manual CI dispatches запускають Android лише з `include_android=true`; full release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, full extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatches окремий workflow `Plugin Prerelease` з увімкненим release-validation gate.
|
||||
|
||||
Manual runs використовують унікальну concurrency group, тому full suite для release candidate не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає змогу trusted caller запускати цей graph для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
|
||||
Manual runs використовують унікальну concurrency group, тому release-candidate full suite не скасовується іншим push або PR run на тому самому ref. Optional input `target_ref` дає trusted caller змогу запустити цей graph для branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref.
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref release/YYYY.M.D
|
||||
@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
|
||||
|
||||
## Runners
|
||||
|
||||
| Запускач | Завдання |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколів/контрактів/пакетних компонентів, шардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агрегатні верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує Ubuntu, розміщений на GitHub, щоб матриця Blacksmith могла ставати в чергу раніше |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші шарди плагінів, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів пакетних плагінів, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тож 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час очікування в черзі 32-vCPU коштував більше, ніж заощаджував) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` в `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` в `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| Виконавець | Завдання |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованих компонентів, сегментовані перевірки контрактів каналів, сегменти `check`, крім lint, сегменти й агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші сегменти розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, сегменти тестів Linux Node, сегменти тестів вбудованих Plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час черги 32-vCPU коштував більше, ніж заощаджував) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; форки повертаються до `macos-latest` |
|
||||
|
||||
## Локальні еквіваленти
|
||||
|
||||
@ -115,25 +115,25 @@ pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-per
|
||||
pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
|
||||
```
|
||||
|
||||
## Повна перевірка релізу
|
||||
## Повна валідація релізу
|
||||
|
||||
`Full Release Validation` — це ручний парасольковий workflow для "запустити все перед релізом". Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження Plugin/пакета/статичних ресурсів/Docker і запускає `OpenClaw Release Checks` для install smoke, приймання пакета, наборів release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і ліній Telegram. Він також може запустити після публікації workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
|
||||
`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає вручну workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження Plugin/пакетів/статичних артефактів/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram-ліній. Він також може запускати після публікації workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
|
||||
|
||||
`release_profile` керує широтою live/provider, яку передають у перевірки релізу:
|
||||
`release_profile` керує шириною live/provider, переданою в release checks:
|
||||
|
||||
- `minimum` залишає найшвидші критичні для релізу лінії OpenAI/core.
|
||||
- `minimum` залишає найшвидші критичні для релізу OpenAI/core лінії.
|
||||
- `stable` додає стабільний набір provider/backend.
|
||||
- `full` запускає широку консультативну матрицю provider/media.
|
||||
- `full` запускає широку advisory-матрицю provider/media.
|
||||
|
||||
Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання-верифікатор, щоб оновити результат парасольки й підсумок часу.
|
||||
Парасолька записує ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок таймінгів.
|
||||
|
||||
Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного дочірнього повного CI, `release-checks` для кожної релізної дочірньої перевірки або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це тримає перезапуск невдалої релізної коробки обмеженим після цільового виправлення.
|
||||
Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного дочірнього full CI, `release-checks` для кожного релізного дочірнього запуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це утримує перезапуск невдалого релізного box у межах після сфокусованого виправлення.
|
||||
|
||||
`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в Docker workflow live/E2E release-path, і в шард приймання пакета. Це зберігає байти пакета узгодженими між релізними коробками й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
|
||||
`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в сегмент package acceptance. Це зберігає байти пакета узгодженими між релізними box і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
|
||||
|
||||
## Live і E2E шарди
|
||||
## Live та E2E-сегменти
|
||||
|
||||
Дочірній live/E2E реліз зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
|
||||
Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані сегменти через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
|
||||
|
||||
- `native-live-src-agents`
|
||||
- `native-live-src-gateway-core`
|
||||
@ -145,57 +145,57 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
- `native-live-extensions-openai`
|
||||
- `native-live-extensions-o-z-other`
|
||||
- `native-live-extensions-xai`
|
||||
- розділені шарди медіа аудіо/відео та відфільтровані за provider шарди музики
|
||||
- розділені audio/video сегменти media та відфільтровані за provider сегменти music
|
||||
|
||||
Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агрегатні назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків.
|
||||
Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск і діагностику повільних збоїв live provider. Агреговані назви сегментів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків.
|
||||
|
||||
Нативні live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з підтримкою Docker на звичайних запускачах Blacksmith — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів.
|
||||
Нативні live media-сегменти працюють у `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з Docker на звичайних runner Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker-тестів.
|
||||
|
||||
Live model/backend шарди з підтримкою Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow один раз збирає й публікує цей образ, після чого шарди Docker live model, Gateway, CLI backend, ACP bind і Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди самостійно перебудовують повну ціль Docker із джерел, релізний прогін налаштовано неправильно, і він марнуватиме загальний час на дубльовані збірки образів.
|
||||
Live-сегменти моделей/backend на базі Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає та публікує цей образ один раз, після чого Docker live model, Gateway, CLI backend, ACP bind і сегменти Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці сегменти самостійно перебудовують повну Docker-ціль source, release run налаштований неправильно й марнуватиме реальний час на дубльовані збірки образів.
|
||||
|
||||
## Приймання пакета
|
||||
## Package Acceptance
|
||||
|
||||
Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево джерел, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі запускають після встановлення або оновлення.
|
||||
Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей інстальований пакет OpenClaw як продукт?» Він відрізняється від звичайного CI: звичайний CI валідує дерево source, тоді як package acceptance валідує один tarball через той самий Docker E2E harness, який користувачі запускають після інсталяції або оновлення.
|
||||
|
||||
### Завдання
|
||||
|
||||
1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, посилання workflow, посилання пакета, версію, SHA-256 та профіль у підсумку кроку GitHub.
|
||||
2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лінії проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
|
||||
3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав його; окремий запуск Telegram усе ще може встановити опубліковану специфікацію npm.
|
||||
4. `summary` провалює workflow, якщо розв’язання пакета, Docker-приймання або опційна лінія Telegram зазнали невдачі.
|
||||
1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить 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 завантажує цей артефакт, валідує інвентар tarball, готує Docker-образи package-digest за потреби та запускає вибрані Docker-лінії проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
|
||||
3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав один; окремий запуск Telegram усе ще може встановити опубліковану npm-специфікацію.
|
||||
4. `summary` провалює workflow, якщо package resolution, Docker acceptance або опційна Telegram-лінія завершилися невдало.
|
||||
|
||||
### Джерела кандидатів
|
||||
|
||||
- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих бета- та стабільних версій.
|
||||
- `source=ref` пакує довірену гілку `package_ref`, тег або повний SHA коміту. Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або з тегу релізу, встановлює залежності у від’єднаному робочому дереві й пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий.
|
||||
- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надавати для артефактів, що поширюються зовнішньо.
|
||||
- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable версій.
|
||||
- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або з релізного тегу, встановлює залежності у від’єднаному worktree та пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
|
||||
- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим.
|
||||
- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надавати для артефактів, якими діляться зовнішньо.
|
||||
|
||||
Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код робочого процесу/тестового оснащення, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому оснащенню перевіряти старіші довірені вихідні коміти без запуску старої логіки робочого процесу.
|
||||
Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає поточному тестовому harness змогу перевіряти старіші довірені вихідні коміти без запуску старої логіки workflow.
|
||||
|
||||
### Профілі наборів
|
||||
|
||||
- `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`, `openai-web-search-minimal`, `openwebui`
|
||||
- `full` — повні Docker-фрагменти шляху релізу з OpenWebUI
|
||||
- `full` — повні фрагменти release-path Docker з OpenWebUI
|
||||
- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
|
||||
|
||||
Профіль `package` використовує офлайн-покриття Plugin, щоб перевірка опублікованого пакета не залежала від доступності ClawHub наживо. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації збережено для автономних запусків.
|
||||
Профіль `package` використовує offline-покриття plugins, щоб перевірка опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої специфікації npm збережено для автономних запусків.
|
||||
|
||||
Перевірки релізу викликають Package Acceptance із `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Docker-фрагменти шляху релізу покривають перехресні лінії пакета/оновлення/Plugin; Package Acceptance зберігає нативну для артефакта перевірку сумісності вбудованих каналів, офлайн-Plugin і Telegram для того самого розв’язаного tarball пакета. Перевірки релізу для різних ОС усе ще покривають специфічне для ОС первинне налаштування, інсталятор і поведінку платформи; продуктову перевірку пакета/оновлення слід починати з Package Acceptance. Свіжі лінії Windows для запакованого пакета й інсталятора також перевіряють, що встановлений пакет може імпортувати перевизначення керування браузером із сирого абсолютного шляху Windows. Димовий тест агентного ходу OpenAI для різних ОС за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його задано, інакше `openai/gpt-5.4-mini`, тому перевірка встановлення й Gateway лишається швидкою та детермінованою.
|
||||
Релізні перевірки викликають Package Acceptance із `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Фрагменти Docker release-path покривають перекривні лінії package/update/plugin; Package Acceptance зберігає artifact-native підтвердження сумісності bundled-channel, offline plugin і Telegram для того самого розв’язаного tarball пакета. Cross-OS релізні перевірки й далі покривають OS-специфічну адаптацію, інсталятор і поведінку платформи; перевірку product для package/update слід починати з Package Acceptance. Лінії Windows packaged та installer fresh також перевіряють, що встановлений пакет може імпортувати browser-control override із сирого абсолютного шляху Windows. Cross-OS agent-turn smoke для OpenAI за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо він заданий, інакше `openai/gpt-5.4-mini`, щоб підтвердження встановлення та Gateway залишалося швидким і детермінованим.
|
||||
|
||||
### Вікна сумісності зі старими версіями
|
||||
### Вікна сумісності зі спадщиною
|
||||
|
||||
Package Acceptance має обмежені вікна сумісності зі старими версіями для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
|
||||
Package Acceptance має обмежені вікна сумісності зі спадщиною для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
|
||||
|
||||
- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
|
||||
- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
|
||||
- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` із фіктивної git-фікстури, отриманої з tarball, і може журналювати відсутній збережений `update.channel`;
|
||||
- димові тести Plugin можуть читати старі розташування записів встановлення або приймати відсутність збереження запису встановлення з маркетплейса;
|
||||
- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб запис встановлення та поведінка без перевстановлення лишалися незмінними.
|
||||
- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, не включені до tarball;
|
||||
- `doctor-switch` може пропустити підвипадок persistence для `gateway install --wrapper`, коли пакет не надає цей прапорець;
|
||||
- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із фейкового git fixture, отриманого з tarball, і може логувати відсутній збережений `update.channel`;
|
||||
- plugin smokes можуть читати застарілі розташування install-record або приймати відсутню persistence marketplace install-record;
|
||||
- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас і далі вимагаючи, щоб install record і поведінка без перевстановлення залишалися незмінними.
|
||||
|
||||
Опублікований пакет `2026.4.26` також може попереджати про файли штампів метаданих локальної збірки, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови спричиняють помилку замість попередження або пропуску.
|
||||
Опублікований пакет `2026.4.26` також може попереджати про файли stamp metadata локального build, які вже були поставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою, а не попередженням чи пропуском.
|
||||
|
||||
### Приклади
|
||||
|
||||
@ -238,152 +238,152 @@ 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`, логи ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю package або точних Docker-ліній замість повторного запуску повної релізної перевірки.
|
||||
|
||||
## Димовий тест встановлення
|
||||
## Install smoke
|
||||
|
||||
Окремий робочий процес `Install Smoke` повторно використовує той самий скрипт області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
|
||||
Окремий workflow `Install Smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
|
||||
|
||||
- **Швидкий шлях** запускається для pull request, які зачіпають поверхні Docker/пакета, зміни пакетів/маніфестів вбудованих Plugin або основні поверхні Plugin/каналу/Gateway/Plugin SDK, які перевіряють Docker-димові завдання. Зміни лише вихідного коду вбудованих Plugin, лише тестові правки та правки лише документації не резервують Docker-воркери. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає димовий тест CLI для видалення агентів спільного робочого простору, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого розширення і запускає обмежений Docker-профіль вбудованих Plugin із 240-секундним сукупним таймаутом команди (кожен Docker-запуск сценарію обмежено окремо).
|
||||
- **Повний шлях** зберігає встановлення QR-пакета й Docker/оновлювальне покриття інсталятора для нічних запланованих запусків, ручних запусків, release checks через workflow-call і pull request, які справді зачіпають поверхні інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ кореневого Dockerfile для димового тесту цільового SHA, а потім запускає встановлення QR-пакета, димові тести кореневого Dockerfile/Gateway, димові тести інсталятора/оновлення і швидкий Docker E2E для вбудованих Plugin як окремі завдання, щоб робота інсталятора не чекала за димовими тестами кореневого образу.
|
||||
- **Швидкий шлях** запускається для pull requests, що торкаються Docker/package поверхонь, змін package/manifest у bundled plugin або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише source у bundled plugin, зміни лише тестів і зміни лише документації не резервують Docker workers. Швидкий шлях один раз збирає image root Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin у межах 240-секундного сукупного timeout команди (Docker-запуск кожного сценарію обмежено окремо).
|
||||
- **Повний шлях** зберігає QR package install та installer Docker/update покриття для нічних запланованих запусків, ручних dispatches, workflow-call релізних перевірок і pull requests, які справді торкаються installer/package/Docker поверхонь. У full mode install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і fast bundled-plugin Docker E2E як окремі jobs, щоб робота installer не чекала за root image smokes.
|
||||
|
||||
Пуші в `main` (зокрема merge-коміти) не примушують повний шлях; коли логіка області змін просила б повне покриття на push, робочий процес зберігає швидкий Docker-димовий тест і залишає повний димовий тест встановлення для нічної або релізної перевірки.
|
||||
Пуші в `main` (зокрема merge commits) не примушують запускати повний шлях; коли логіка changed-scope вимагала б повного покриття під час push, workflow зберігає fast Docker smoke і залишає full install smoke для нічної або релізної перевірки.
|
||||
|
||||
Повільний димовий тест Bun global install image-provider окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні запуски `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` — ні. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на встановленні.
|
||||
Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow релізних перевірок, а ручні dispatches `Install Smoke` можуть увімкнути його, але pull requests і пуші в `main` — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
|
||||
|
||||
## Локальний Docker E2E
|
||||
|
||||
`pnpm test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
|
||||
`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні images `scripts/e2e/Dockerfile`:
|
||||
|
||||
- базовий Node/Git runner для ліній інсталятора/оновлення/залежностей Plugin;
|
||||
- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
|
||||
- bare Node/Git runner для ліній installer/update/plugin-dependency;
|
||||
- функціональний image, який встановлює той самий 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`.
|
||||
Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає image для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
|
||||
### Параметри налаштування
|
||||
### Налаштування
|
||||
|
||||
| Змінна | Типово | Призначення |
|
||||
| ------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------ |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів хвостового пулу для чутливих до провайдерів ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження одночасних live-ліній, щоб провайдери не застосовували throttling. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження одночасних ліній встановлення npm. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження одночасних багатосервісних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникати штормів створення в Docker daemon; задайте `0`, щоб вимкнути її. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний таймаут для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` виводить план планувальника без запуску ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Розділений комами точний список ліній; пропускає димове очищення, щоб агенти могли відтворити одну невдалу лінію. |
|
||||
| Змінна | Значення за замовчуванням | Призначення |
|
||||
| ------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів main-pool для звичайних ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-pool, чутливого до provider. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live-ліній, щоб providers не застосовували throttling. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних ліній npm install. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникнути create storms Docker daemon; задайте `0`, щоб вимкнути stagger. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний timeout для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план scheduler без запуску ліній. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | unset | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. |
|
||||
|
||||
Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальна сукупна перевірка спершу перевіряє Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних ліній, зберігає тривалості ліній для впорядкування від найдовших і за замовчуванням припиняє планування нових pooled ліній після першої помилки.
|
||||
Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього pool, а потім працює сама, доки не звільнить capacity. Локальний aggregate виконує preflight Docker, видаляє застарілі OpenClaw E2E containers, виводить status активних ліній, зберігає таймінги ліній для впорядкування longest-first і за замовчуванням припиняє планувати нові pooled лінії після першої помилки.
|
||||
|
||||
### Перевикористовуваний live/E2E робочий процес
|
||||
### Багаторазовий live/E2E workflow
|
||||
|
||||
Перевикористовуваний live/E2E робочий процес запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub-виводи й зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує до GHCR bare/functional Docker E2E образи з тегом digest пакета через кеш Docker-шарів Blacksmith, коли план потребує ліній зі встановленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з digest пакета замість перебудови. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий потік реєстру/кешу швидко повторився, а не споживав більшу частину критичного шляху CI.
|
||||
Багаторазовий live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, які package, image kind, live image, lane і credential coverage потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, або завантажує package artifact поточного запуску, або завантажує package artifact з `package_artifact_run_id`; перевіряє inventory tarball; збирає та пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли план потребує ліній із установленим package; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Docker image pulls повторюються з обмеженим 180-секундним timeout на спробу, щоб завислий registry/cache stream швидко повторився замість споживання більшої частини критичного шляху CI.
|
||||
|
||||
### Фрагменти шляху релізу
|
||||
### Фрагменти release-path
|
||||
|
||||
Релізне Docker-покриття запускає менші фрагментовані завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник:
|
||||
Релізне Docker-покриття запускає менші chunked jobs із `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний йому kind image і виконував кілька ліній через той самий зважений 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..h | bundled-channels`
|
||||
|
||||
Поточні Docker-фрагменти релізу: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, від `plugins-runtime-install-a` до `plugins-runtime-install-h`, `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` залишаються агрегованими псевдонімами Plugin/середовища виконання. Псевдонім смуги `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох смуг інсталяторів провайдерів. Фрагмент `bundled-channels` запускає розділені смуги `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну універсальну смугу `bundled-channel-deps`.
|
||||
Поточні фрагменти Docker для випуску: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, від `plugins-runtime-install-a` до `plugins-runtime-install-h`, `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` залишаються агрегованими псевдонімами для plugin/runtime. Псевдонім смуги `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох смуг інсталяторів провайдерів. Фрагмент `bundled-channels` запускає розділені смуги `bundled-channel-*` і `bundled-channel-update-*` замість послідовної універсальної смуги `bundled-channel-deps`.
|
||||
|
||||
OpenWebUI включається до `plugins-runtime-services`, коли повне покриття шляху релізу цього вимагає, і зберігає окремий фрагмент `openwebui` лише для dispatch-запусків, призначених тільки для OpenWebUI. Смуги оновлення bundled-channel виконують одну повторну спробу в разі тимчасових мережевих збоїв npm.
|
||||
OpenWebUI включається в `plugins-runtime-services`, коли повне покриття шляху випуску цього вимагає, і зберігає окремий фрагмент `openwebui` лише для dispatch-запусків, що стосуються тільки OpenWebUI. Смуги оновлення bundled-channel повторюють спробу один раз для тимчасових мережевих збоїв npm.
|
||||
|
||||
Кожен фрагмент завантажує `.artifacts/docker-tests/` із журналами смуг, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Вхід `docker_lanes` workflow запускає вибрані смуги проти підготовлених образів замість завдань фрагментів, що обмежує налагодження збійної смуги одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker-смугою, цільове завдання локально збирає образ live-test для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної смуги включають `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, тож збійна смуга може повторно використати точний пакет і образи зі збійного запуску.
|
||||
Кожен фрагмент завантажує `.artifacts/docker-tests/` із журналами смуг, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Вхід workflow `docker_lanes` запускає вибрані смуги проти підготовлених образів замість завдань фрагментів, що обмежує налагодження невдалої смуги одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker-смугою, цільове завдання локально збирає образ live-test для такого повторного запуску. Згенеровані команди GitHub для повторного запуску окремих смуг містять `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, щоб невдала смуга могла повторно використати точні пакет і образи з невдалого запуску.
|
||||
|
||||
```bash
|
||||
pnpm test:docker:rerun <run-id> # завантажити Docker-артефакти та вивести об'єднані/посмугові цільові команди повторного запуску
|
||||
pnpm test:docker:timings <summary> # зведення повільних смуг і критичного шляху фаз
|
||||
pnpm test:docker:rerun <run-id> # download Docker artifacts and print combined/per-lane targeted rerun commands
|
||||
pnpm test:docker:timings <summary> # slow-lane and phase critical-path summaries
|
||||
```
|
||||
|
||||
Запланований live/E2E workflow щодня запускає повний Docker-набір шляху релізу.
|
||||
Запланований live/E2E workflow щодня запускає повний Docker-набір для шляху випуску.
|
||||
|
||||
## Попередній реліз Plugin
|
||||
## Попередній випуск Plugin
|
||||
|
||||
`Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push до `main` і самостійні ручні CI dispatch-запуски залишають цей набір вимкненим. Він балансує тести bundled Plugin між вісьмома extension workers; ці завдання extension shard запускають до двох груп конфігурації Plugin одночасно з одним Vitest worker на групу та більшим heap Node, щоб насичені імпортами пакети Plugin не створювали додаткових CI-завдань.
|
||||
`Plugin Prerelease` — це дорожче покриття продукту/пакета, тому воно є окремим workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push до `main` і окремі ручні CI dispatch-запуски залишають цей набір вимкненим. Він балансує тести bundled plugin між вісьмома extension workers; ці shard-завдання розширень запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу й більшим heap Node, щоб насичені імпортами пакети plugin не створювали додаткових CI-завдань.
|
||||
|
||||
## Лабораторія QA
|
||||
## QA Lab
|
||||
|
||||
Лабораторія QA має спеціальні CI-смуги поза основним smart-scoped workflow.
|
||||
QA Lab має виділені CI-смуги поза основним smart-scoped workflow.
|
||||
|
||||
- Workflow `Parity gate` запускається за відповідних змін у PR і ручного dispatch; він збирає приватне середовище виконання QA та порівнює агентні пакети mock GPT-5.5 і Opus 4.6.
|
||||
- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручного dispatch; він розгалужує mock parity gate, live Matrix-смугу та live Telegram і Discord смуги як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують lease-и Convex.
|
||||
- Workflow `Parity gate` запускається для відповідних змін PR і ручного dispatch; він збирає приватний runtime QA та порівнює агентні пакети mock GPT-5.5 і Opus 4.6.
|
||||
- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і під час ручного dispatch; він розгортає mock parity gate, live-смугу Matrix і live-смуги Telegram та Discord як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
|
||||
|
||||
Перевірки релізу запускають live transport-смуги Matrix і Telegram з детермінованим mock-провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного запуску provider-plugin. Live transport Gateway вимикає пошук пам'яті, оскільки parity QA окремо покриває поведінку пам'яті; з'єднання з провайдером покриваються окремими наборами live model, native provider і Docker provider.
|
||||
Перевірки випуску запускають live transport-смуги Matrix і Telegram із детермінованим mock provider та mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model і звичайного запуску provider-plugin. Live transport gateway вимикає пошук пам’яті, оскільки QA parity окремо покриває поведінку пам’яті; зв’язність провайдера покривається окремими наборами live model, native provider і Docker provider.
|
||||
|
||||
Matrix використовує `--profile fast` для запланованих перевірок і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Типове значення CLI і вхід manual workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розділяє повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
|
||||
Matrix використовує `--profile fast` для запланованих і release-gate запусків, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Стандартне значення CLI і ручний вхід workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди ділить повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
|
||||
|
||||
`OpenClaw Release Checks` також запускає критичні для релізу смуги QA Lab перед затвердженням релізу; його QA parity gate запускає candidate і baseline пакети як паралельні завдання смуг, а потім завантажує обидва артефакти в невелике звітне завдання для фінального порівняння parity.
|
||||
`OpenClaw Release Checks` також запускає критичні для випуску смуги QA Lab перед затвердженням випуску; його QA parity gate запускає кандидатні та базові пакети як паралельні lane-завдання, а потім завантажує обидва артефакти в невелике report-завдання для фінального порівняння parity.
|
||||
|
||||
Не ставте шлях landing для PR за `Parity gate`, якщо зміна фактично не торкається середовища виконання QA, parity model-pack або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test вважайте це необов'язковим сигналом і натомість дотримуйтеся scoped CI/check evidence.
|
||||
Не ставте шлях landing для PR за `Parity gate`, якщо зміна фактично не торкається runtime QA, parity model-pack або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте це як необов’язковий сигнал і спирайтеся на scoped CI/check докази.
|
||||
|
||||
## CodeQL
|
||||
|
||||
Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та guard-запуски для non-draft pull request сканують код Actions workflow плюс JavaScript/TypeScript-поверхні найвищого ризику з high-confidence security-запитами, відфільтрованими до high/critical `security-severity`.
|
||||
Workflow `CodeQL` навмисно є вузьким первинним сканером безпеки, а не повним скануванням репозиторію. Щоденні, ручні й guard-запуски для non-draft pull request сканують код Actions workflow плюс найризиковіші поверхні JavaScript/TypeScript за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`.
|
||||
|
||||
Guard для pull request залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security-матрицю, що й запланований workflow. Android і macOS CodeQL залишаються поза типовими PR-перевірками.
|
||||
Guard для pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму high-confidence security matrix, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків.
|
||||
|
||||
### Категорії безпеки
|
||||
|
||||
| Категорія | Поверхня |
|
||||
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | Базовий рівень auth, secrets, sandbox, cron і gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс середовище виконання channel plugin, gateway, Plugin SDK, secrets, audit touchpoints |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Поверхні політики SSRF для core SSRF, розбору IP, network guard, web-fetch і Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, outbound delivery і gates виконання інструментів агентом |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для встановлення Plugin, loader, manifest, registry, staging runtime-dependency, source-loading і контракту пакета Plugin SDK |
|
||||
| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і базова лінія gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс runtime channel plugin, gateway, Plugin SDK, secrets, audit touchpoints |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | Поверхні core SSRF, IP parsing, network guard, web-fetch і політики SSRF у Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і agent tool-execution gates |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для install plugin, loader, manifest, registry, runtime-dependency staging, source-loading і package contract Plugin SDK |
|
||||
|
||||
### Платформо-специфічні security shards
|
||||
### Платформоспецифічні security shards
|
||||
|
||||
- `CodeQL Android Critical Security` — запланований Android security shard. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза щоденними типовими перевірками, бо збірка macOS домінує час виконання навіть у чистому стані.
|
||||
- `CodeQL Android Critical Security` — запланований Android security shard. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза щоденними стандартними запускми, оскільки macOS build домінує час виконання навіть коли чистий.
|
||||
|
||||
### Категорії критичної якості
|
||||
### Категорії Critical Quality
|
||||
|
||||
`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality-запити над вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: non-draft PR запускають лише відповідні shards `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у channel runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, контракті Plugin SDK/package або Plugin SDK reply runtime. Зміни конфігурації CodeQL і quality workflow запускають усі дев'ять PR quality shards.
|
||||
`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких high-value поверхнях на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: non-draft PR запускають лише відповідні shards `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у auth/secrets/sandbox/security code, channel runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі десять PR quality shards.
|
||||
|
||||
Ручний dispatch приймає:
|
||||
|
||||
```
|
||||
profile=all|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
profile=all|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
```
|
||||
|
||||
Вузькі профілі — це hooks для навчання/ітерації, щоб запускати один quality shard ізольовано.
|
||||
Вузькі профілі — це teaching/iteration hooks для запуску одного quality shard ізольовано.
|
||||
|
||||
| Категорія | Поверхня |
|
||||
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, пісочниці, Cron і Gateway |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, sandbox, cron і Gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та контракти IO |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти методів сервера |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основних каналів |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделі/провайдера, диспетчеризація автовідповідей і черги, а також контракти середовища виконання площини керування ACP |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, маршрутизація моделей/провайдерів, маршрутизація та черги автовідповідей, а також runtime-контракти control plane ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP і мости інструментів, допоміжні засоби нагляду за процесами та контракти вихідної доставки |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, фасади середовища виконання пам’яті, псевдоніми SDK Plugin пам’яті, зв’язувальний код активації середовища виконання пам’яті та команди doctor для пам’яті |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, runtime-фасади пам’яті, псевдоніми SDK пам’яті Plugin, зв’язувальний код активації runtime пам’яті та команди doctor для пам’яті |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня логіка черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/пакетів журналів і контракти CLI doctor для сеансів |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей SDK Plugin, допоміжні засоби для payload/chunking/runtime відповідей, параметри відповідей каналів, черги доставки та допоміжні засоби прив’язування сеансів/потоків |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та виявлення провайдерів, реєстрація середовища виконання провайдерів, типові параметри/каталоги провайдерів і реєстри web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Початкове завантаження Control UI, локальне збереження, потоки керування Gateway і контракти середовища виконання площини керування завданнями |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Контракти середовища виконання для основних web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та точок входу SDK Plugin |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковане джерело SDK Plugin на боці пакета та допоміжні засоби контракту пакета plugin |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Вхідна маршрутизація відповідей SDK Plugin, допоміжні засоби payload/розбиття на частини/runtime для відповідей, параметри відповіді каналу, черги доставки та допоміжні засоби прив’язування сеансів/потоків |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та виявлення провайдерів, реєстрація runtime провайдерів, стандартні налаштування/каталоги провайдерів і реєстри web/search/fetch/embedding |
|
||||
| `/codeql-critical-quality/ui-control-plane` | Завантаження Control UI, локальне збереження, потоки керування Gateway і runtime-контракти control plane задач |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | Контракти runtime для основних web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа |
|
||||
| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint SDK Plugin |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований вихідний код SDK Plugin з боку пакета та допоміжні засоби контракту пакета plugin |
|
||||
|
||||
Якість залишається окремою від безпеки, щоб знахідки щодо якості можна було планувати, вимірювати, вимикати або розширювати без розмивання сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як обмежену за областю або розшардовану подальшу роботу лише після того, як вузькі профілі матимуть стабільне середовище виконання та сигнал.
|
||||
Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без розмивання сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
|
||||
|
||||
## Робочі процеси обслуговування
|
||||
## Робочі процеси супроводу
|
||||
|
||||
### Docs Agent
|
||||
### Агент документації
|
||||
|
||||
Робочий процес `Docs Agent` — це подієво керована лінія обслуговування Codex для підтримання узгодженості наявної документації з нещодавно внесеними змінами. Він не має суто розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього непропущеного вихідного SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
|
||||
Робочий процес `Docs Agent` — це подієво-керована лінія супроводу Codex для підтримання наявної документації узгодженою з нещодавно landed змінами. Він не має суто розкладу: успішний CI-запуск для неботівського push на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено за останню годину. Коли він запускається, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації.
|
||||
|
||||
### Test Performance Agent
|
||||
### Агент продуктивності тестів
|
||||
|
||||
Робочий процес `Test Performance Agent` — це подієво керована лінія обслуговування Codex для повільних тестів. Він не має суто розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей денний шлюз активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору тестів, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт для повного набору тестів і відхиляє зміни, які зменшують базову кількість прохідних тестів. Якщо в базовому стані є тести, що падають, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push буде внесено, лінія rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб action Codex міг зберігати ту саму безпечну позицію drop-sudo, що й docs agent.
|
||||
Робочий процес `Test Performance Agent` — це подієво-керована лінія супроводу Codex для повільних тестів. Він не має суто розкладу: успішний CI-запуск для неботівського push на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей денний gate активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, які зменшують базову кількість тестів, що проходять. Якщо baseline має тести, що падають, Codex може виправляти лише очевидні помилки, а звіт повного набору після агента має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push буде landed, лінія робить rebase перевіреного patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберегти таку саму drop-sudo позицію безпеки, як агент документації.
|
||||
|
||||
### Дублікати PR після merge
|
||||
### Дублікати PR після злиття
|
||||
|
||||
Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес maintainer для очищення дублікатів після внесення. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що внесений PR змержено і що кожен дублікат має або спільне згадане issue, або перетин змінених hunks.
|
||||
Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після land. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злито і що кожен дублікат має або спільну referenced issue, або перетин змінених hunks.
|
||||
|
||||
```bash
|
||||
gh workflow run duplicate-after-merge.yml \
|
||||
@ -392,27 +392,27 @@ gh workflow run duplicate-after-merge.yml \
|
||||
-f apply=true
|
||||
```
|
||||
|
||||
## Локальні шлюзи перевірок і маршрутизація змін
|
||||
## Локальні check gates і маршрутизація змін
|
||||
|
||||
Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний шлюз перевірки суворіший щодо архітектурних меж, ніж широка область платформи CI:
|
||||
Логіка локальних changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI:
|
||||
|
||||
- зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards;
|
||||
- зміни лише тестів core запускають тільки typecheck core test плюс core lint;
|
||||
- зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint;
|
||||
- зміни лише тестів extension запускають typecheck extension test плюс extension lint;
|
||||
- зміни публічного SDK Plugin або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих контрактів core (прогони Vitest extension залишаються явною тестовою роботою);
|
||||
- version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
|
||||
- невідомі зміни root/config fail safe до всіх check lanes.
|
||||
- зміни core production запускають typecheck core prod і core test плюс core lint/guards;
|
||||
- зміни лише core test запускають тільки typecheck core test плюс core lint;
|
||||
- зміни extension production запускають typecheck extension prod і extension test плюс extension lint;
|
||||
- зміни лише extension test запускають typecheck extension test плюс extension lint;
|
||||
- зміни публічного SDK Plugin або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core contracts (sweeps Vitest для extension залишаються явною тестовою роботою);
|
||||
- metadata-only підняття версії для релізу запускають цільові перевірки version/config/root-dependency;
|
||||
- невідомі root/config зміни безпечно падають до всіх check lanes.
|
||||
|
||||
Локальна маршрутизація changed-test живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, редагування джерел віддають перевагу явним мапінгам, потім sibling tests і залежним від import-graph. Конфігурація доставки shared group-room є одним із явних мапінгів: зміни до конфігурації видимих відповідей групи, режиму доставки відповідей з джерела або системного prompt для message-tool маршрутизуються через основні тести відповідей плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий mapped set не є надійним proxy.
|
||||
Локальна маршрутизація changed-test живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, редагування вихідного коду віддають перевагу явним mappings, потім sibling tests і залежним з import graph. Конфігурація доставки спільної group-room є одним із явних mappings: зміни до конфігурації visible-reply групи, режиму доставки source reply або system prompt message-tool маршрутизуються через core reply tests плюс регресії доставки Discord і Slack, щоб зміна спільного default впала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий mapped set не є надійним proxy.
|
||||
|
||||
## Валідація Testbox
|
||||
|
||||
Запускайте Testbox з кореня repo і для широкого proof віддавайте перевагу свіжому прогрітому box. Перед тим як витрачати повільний gate на box, який повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині box.
|
||||
Запускайте Testbox з кореня репозиторію і віддавайте перевагу свіжому warmed box для широкого proof. Перед витрачанням повільного gate на box, який був повторно використаний, протермінований або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box.
|
||||
|
||||
Sanity check швидко падає, коли обов’язкові root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і прогрійте новий замість налагодження збою product test. Для навмисних PR із великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
|
||||
Sanity check швидко падає, коли потрібні root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цей box і warm свіжий замість debug збою product test. Для навмисних PR з великим видаленням встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
|
||||
|
||||
`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих локальних diff.
|
||||
`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих local diffs.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user