chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
f3487447e3
commit
1520aa5369
157
docs/uk/channels/matrix-push-rules.md
Normal file
157
docs/uk/channels/matrix-push-rules.md
Normal file
@ -0,0 +1,157 @@
|
||||
---
|
||||
read_when:
|
||||
- Налаштування тихої потокової передачі Matrix для самохостингового Synapse або Tuwunel
|
||||
- Користувачі хочуть отримувати сповіщення лише про завершені блоки, а не про кожне редагування попереднього перегляду
|
||||
summary: Правила push-сповіщень Matrix для тихих фіналізованих редагувань попереднього перегляду
|
||||
title: Правила push-сповіщень Matrix для тихих попередніх переглядів
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T15:01:14Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: dbfdf2552ca352858d4e8d03a2a0f5f3b420d33b01063c111c0335c0229f0534
|
||||
source_path: channels/matrix-push-rules.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Правила push-сповіщень Matrix для тихих попередніх переглядів
|
||||
|
||||
Коли `channels.matrix.streaming` має значення `"quiet"`, OpenClaw редагує одну подію попереднього перегляду на місці й позначає фіналізоване редагування спеціальним прапорцем у вмісті. Клієнти Matrix надсилають сповіщення лише про фінальне редагування, якщо правило push для конкретного користувача відповідає цьому прапорцю. Ця сторінка призначена для операторів, які самостійно хостять Matrix і хочуть встановити це правило для кожного облікового запису одержувача.
|
||||
|
||||
Якщо вам потрібна лише стандартна поведінка сповіщень Matrix, використовуйте `streaming: "partial"` або залиште потокову передачу вимкненою. Див. [Налаштування каналу Matrix](/uk/channels/matrix#streaming-previews).
|
||||
|
||||
## Передумови
|
||||
|
||||
- користувач-одержувач = людина, яка має отримувати сповіщення
|
||||
- бот-користувач = обліковий запис OpenClaw Matrix, який надсилає відповідь
|
||||
- для наведених нижче викликів API використовуйте токен доступу користувача-одержувача
|
||||
- у правилі push значення `sender` має збігатися з повним MXID бот-користувача
|
||||
- обліковий запис одержувача вже повинен мати справні pushers — правила тихого попереднього перегляду працюють лише тоді, коли звичайна доставка push у Matrix працює коректно
|
||||
|
||||
## Кроки
|
||||
|
||||
<Steps>
|
||||
<Step title="Налаштуйте тихі попередні перегляди">
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
matrix: {
|
||||
streaming: "quiet",
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Отримайте токен доступу одержувача">
|
||||
Повторно використайте токен наявної сесії клієнта, якщо це можливо. Щоб випустити новий:
|
||||
|
||||
```bash
|
||||
curl -sS -X POST \
|
||||
"https://matrix.example.org/_matrix/client/v3/login" \
|
||||
-H "Content-Type: application/json" \
|
||||
--data '{
|
||||
"type": "m.login.password",
|
||||
"identifier": { "type": "m.id.user", "user": "@alice:example.org" },
|
||||
"password": "REDACTED"
|
||||
}'
|
||||
```
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Переконайтеся, що pushers існують">
|
||||
|
||||
```bash
|
||||
curl -sS \
|
||||
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
|
||||
"https://matrix.example.org/_matrix/client/v3/pushers"
|
||||
```
|
||||
|
||||
Якщо pushers не повертаються, спочатку виправте звичайну доставку push у Matrix для цього облікового запису.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Встановіть override-правило push">
|
||||
OpenClaw позначає фіналізовані редагування текстового попереднього перегляду через `content["com.openclaw.finalized_preview"] = true`. Встановіть правило, яке відповідає цьому маркеру, а також MXID бота як відправнику:
|
||||
|
||||
```bash
|
||||
curl -sS -X PUT \
|
||||
"https://matrix.example.org/_matrix/client/v3/pushrules/global/override/openclaw-finalized-preview-botname" \
|
||||
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
--data '{
|
||||
"conditions": [
|
||||
{ "kind": "event_match", "key": "type", "pattern": "m.room.message" },
|
||||
{
|
||||
"kind": "event_property_is",
|
||||
"key": "content.m\\.relates_to.rel_type",
|
||||
"value": "m.replace"
|
||||
},
|
||||
{
|
||||
"kind": "event_property_is",
|
||||
"key": "content.com\\.openclaw\\.finalized_preview",
|
||||
"value": true
|
||||
},
|
||||
{ "kind": "event_match", "key": "sender", "pattern": "@bot:example.org" }
|
||||
],
|
||||
"actions": [
|
||||
"notify",
|
||||
{ "set_tweak": "sound", "value": "default" },
|
||||
{ "set_tweak": "highlight", "value": false }
|
||||
]
|
||||
}'
|
||||
```
|
||||
|
||||
Перед запуском замініть:
|
||||
|
||||
- `https://matrix.example.org`: базовий URL вашого homeserver
|
||||
- `$USER_ACCESS_TOKEN`: токен доступу користувача-одержувача
|
||||
- `openclaw-finalized-preview-botname`: ID правила, унікальний для кожного бота й одержувача (шаблон: `openclaw-finalized-preview-<botname>`)
|
||||
- `@bot:example.org`: MXID вашого бота OpenClaw, а не одержувача
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Перевірте">
|
||||
|
||||
```bash
|
||||
curl -sS \
|
||||
-H "Authorization: Bearer $USER_ACCESS_TOKEN" \
|
||||
"https://matrix.example.org/_matrix/client/v3/pushrules/global/override/openclaw-finalized-preview-botname"
|
||||
```
|
||||
|
||||
Потім протестуйте потокову відповідь. У тихому режимі в кімнаті показується чернетка тихого попереднього перегляду, а сповіщення надходить один раз, коли блок або хід завершується.
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Щоб пізніше видалити правило, виконайте `DELETE` для того самого URL правила з токеном одержувача.
|
||||
|
||||
## Примітки щодо кількох ботів
|
||||
|
||||
Ключем push-правил є `ruleId`: повторний запуск `PUT` для того самого ID оновлює одне правило. Якщо кілька ботів OpenClaw надсилають сповіщення одному одержувачу, створіть окреме правило для кожного бота з різним збігом `sender`.
|
||||
|
||||
Нові користувацькі правила `override` вставляються перед стандартними правилами приглушення, тому жоден додатковий параметр упорядкування не потрібен. Правило впливає лише на редагування текстового попереднього перегляду, які можна фіналізувати на місці; резервні варіанти для медіа та застарілого попереднього перегляду використовують звичайну доставку Matrix.
|
||||
|
||||
## Примітки щодо homeserver
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Synapse">
|
||||
Спеціальні зміни в `homeserver.yaml` не потрібні. Якщо звичайні сповіщення Matrix уже доходять до цього користувача, головний крок налаштування — це токен одержувача та виклик `pushrules`, наведений вище.
|
||||
|
||||
Якщо ви запускаєте Synapse за reverse proxy або workers, переконайтеся, що `/_matrix/client/.../pushrules/` коректно доходить до Synapse. Доставка push обробляється основним процесом або `synapse.app.pusher` / налаштованими pusher workers — переконайтеся, що вони працюють справно.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Tuwunel">
|
||||
Такий самий процес, як і для Synapse; жодна специфічна для Tuwunel конфігурація для маркера фіналізованого попереднього перегляду не потрібна.
|
||||
|
||||
Якщо сповіщення зникають, поки користувач активний на іншому пристрої, перевірте, чи ввімкнено `suppress_push_when_active`. Tuwunel додав цю опцію у версії 1.4.2 (вересень 2025 року), і вона може навмисно приглушувати push на інших пристроях, поки один пристрій активний.
|
||||
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Налаштування каналу Matrix](/uk/channels/matrix)
|
||||
- [Концепції потокової передачі](/uk/concepts/streaming)
|
||||
File diff suppressed because it is too large
Load Diff
113
docs/uk/ci.md
113
docs/uk/ci.md
@ -2,99 +2,100 @@
|
||||
read_when:
|
||||
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
|
||||
- Ви налагоджуєте збої перевірок GitHub Actions
|
||||
summary: Граф завдань CI, перевірки за областю змін і локальні еквіваленти команд
|
||||
summary: Граф завдань CI, обмеження області дії та локальні еквіваленти команд
|
||||
title: Конвеєр CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T14:40:11Z"
|
||||
generated_at: "2026-04-23T15:01:12Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: b9ab8559ab9ac781ae87f94374840a21a0c588e7cd289c6bb8a8cd07e8df6083
|
||||
source_hash: e9a03440ae28a15167fc08d9c66bb1fd719ddfa1517aaecb119c80f2ad826c0d
|
||||
source_path: ci.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
# Конвеєр CI
|
||||
|
||||
CI запускається для кожного push до `main` і для кожного pull request. Він використовує розумне визначення області змін, щоб пропускати дорогі завдання, коли змінювалися лише не пов’язані між собою частини.
|
||||
CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне обмеження області дії, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки.
|
||||
|
||||
QA Lab має окремі смуги CI поза основним робочим процесом із розумним визначенням області змін. Робочий процес `Parity gate` запускається для відповідних змін у PR і через ручний запуск; він збирає приватне середовище виконання QA та порівнює агентні пакети mock GPT-5.4 і Opus 4.6. Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і через ручний запуск; він розгалужує mock parity gate, live Matrix lane і live Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а смуга Telegram використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі смуги QA Lab перед погодженням релізу.
|
||||
QA Lab має окремі смуги CI поза основним робочим процесом із розумним обмеженням області. Робочий процес `Parity gate` запускається для відповідних змін у PR і через ручний запуск; він збирає приватне середовище виконання QA та порівнює агентні пакети mock GPT-5.4 і Opus 4.6. Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і через ручний запуск; він розгалужує mock parity gate, live Matrix lane і live Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а смуга Telegram використовує Convex leases. `OpenClaw Release Checks` також запускає ті самі смуги QA Lab перед погодженням релізу.
|
||||
|
||||
## Огляд завдань
|
||||
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- |
|
||||
| `preflight` | Визначає зміни лише в документації, змінені області, змінені extensions і формує CI-маніфест | Завжди для push і PR, що не є draft |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory з npm | Завжди для push і PR, що не є draft |
|
||||
| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для push і PR, що не є draft |
|
||||
| `build-artifacts` | Збирає `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані downstream-артефакти | Зміни, релевантні для Node |
|
||||
| `checks-fast-core` | Швидкі Linux-смуги коректності, як-от bundled/plugin-contract/protocol перевірки | Зміни, релевантні для Node |
|
||||
| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node |
|
||||
| `checks-node-extensions` | Повні шардовані тести bundled-plugin у всьому наборі extension | Зміни, релевантні для Node |
|
||||
| `checks-node-core-test` | Шарди основних Node-тестів, без смуг каналів, bundled, контрактів і extension | Зміни, релевантні для Node |
|
||||
| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами в extension |
|
||||
| `check` | Шардований еквівалент основної локальної перевірки: production types, lint, guards, test types і strict smoke | Зміни, релевантні для Node |
|
||||
| `check-additional` | Архітектурні перевірки, перевірки меж, surface guards для extension, package-boundary і шарди gateway-watch | Зміни, релевантні для Node |
|
||||
| `build-smoke` | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску | Зміни, релевантні для Node |
|
||||
| `checks` | Верифікатор для тестів каналів на зібраних артефактах плюс лише для push — сумісність із Node 22 | Зміни, релевантні для Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірки на зламані посилання | Змінено документацію |
|
||||
| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні для Python Skills |
|
||||
| `checks-windows` | Специфічні для Windows тестові смуги | Зміни, релевантні для Windows |
|
||||
| `macos-node` | Смуга TypeScript-тестів на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
|
||||
| `macos-swift` | Swift lint, збірка і тести для застосунку macOS | Зміни, релевантні для macOS |
|
||||
| `android` | Android unit-тести для обох flavor плюс одна збірка debug APK | Зміни, релевантні для Android |
|
||||
| Завдання | Призначення | Коли запускається |
|
||||
| -------------------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------ |
|
||||
| `preflight` | Визначення змін лише в документації, змінених областей, змінених розширень і побудова маніфесту CI | Завжди для push і PR, що не є draft |
|
||||
| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для push і PR, що не є draft |
|
||||
| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisory npm | Завжди для push і PR, що не є draft |
|
||||
| `security-fast` | Обов’язковий агрегатор для швидких завдань безпеки | Завжди для push і PR, що не є draft |
|
||||
| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built-artifact і багаторазово використовуваних downstream-артефактів | Зміни, релевантні Node |
|
||||
| `checks-fast-core` | Швидкі Linux-смуги коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні Node |
|
||||
| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні Node |
|
||||
| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору extension | Зміни, релевантні Node |
|
||||
| `checks-node-core-test` | Шарди тестів core Node, без смуг каналів, bundled, contract і extension | Зміни, релевантні Node |
|
||||
| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами в extension |
|
||||
| `check` | Шардований еквівалент основного локального gate: production types, lint, guards, test types і strict smoke | Зміни, релевантні Node |
|
||||
| `check-additional` | Шарди architecture, boundary, extension-surface guards, package-boundary і gateway-watch | Зміни, релевантні Node |
|
||||
| `build-smoke` | Smoke-тести built-CLI і smoke перевірка пам’яті під час запуску | Зміни, релевантні Node |
|
||||
| `checks` | Верифікатор для channel-тестів built-artifact плюс сумісність Node 22 лише для push | Зміни, релевантні Node |
|
||||
| `check-docs` | Форматування документації, lint і перевірки зламаних посилань | Документацію змінено |
|
||||
| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні Python Skills |
|
||||
| `checks-windows` | Windows-специфічні тестові смуги | Зміни, релевантні Windows |
|
||||
| `macos-node` | Смуга тестів TypeScript на macOS з використанням спільних built artifacts | Зміни, релевантні macOS |
|
||||
| `macos-swift` | Lint, збірка та тести Swift для застосунку macOS | Зміни, релевантні macOS |
|
||||
| `android` | Юніт-тести Android для обох flavor плюс одна збірка debug APK | Зміни, релевантні Android |
|
||||
|
||||
## Порядок fail-fast
|
||||
|
||||
Завдання впорядковані так, щоб дешеві перевірки падали раніше, ніж почнуть працювати дорогі:
|
||||
Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
|
||||
|
||||
1. `preflight` вирішує, які смуги взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи на важчі завдання з артефактами та платформними матрицями.
|
||||
2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються швидко, не чекаючи важчих матричних завдань артефактів і платформ.
|
||||
3. `build-artifacts` виконується паралельно зі швидкими Linux-смугами, щоб downstream-споживачі могли стартувати, щойно спільна збірка буде готова.
|
||||
4. Після цього розгалужуються важчі платформні та runtime-смуги: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, лише для PR — `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
4. Після цього розгалужуються важчі платформні та runtime-смуги: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, PR-only `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
|
||||
|
||||
Логіка області змін міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Зміни workflow CI перевіряють граф Node CI плюс lint workflow, але самі по собі не змушують виконувати нативні збірки для Windows, Android або macOS; ці платформні смуги й далі визначаються лише змінами у платформному коді.
|
||||
Перевірки Windows Node обмежені Windows-специфічними обгортками для process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цю смугу; не пов’язані зміни вихідного коду, plugin, install-smoke і зміни лише в тестах залишаються в Linux Node lanes, щоб не резервувати 16-vCPU Windows worker для покриття, яке вже проходить у звичайних тестових шардах.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт області змін через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, пов’язаних з інсталяцією, пакуванням, контейнерами, production-змінами bundled extension і поверхнями core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише в тестах і лише в документації не резервують Docker workers. Його QR package smoke примусово повторно запускає шар Docker `pnpm install`, зберігаючи кеш BuildKit pnpm store, тож він і далі перевіряє встановлення без повторного завантаження залежностей на кожному запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в цьому завданні, тож додає реальне WebSocket-покриття container-to-container без додавання ще однієї Docker-збірки. Локальний `test:docker:all` попередньо збирає один спільний live-test image і один спільний image зібраного застосунку `scripts/e2e/Dockerfile`, а потім паралельно запускає live/E2E smoke lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте стандартний рівень паралелізму 4 через `OPENCLAW_DOCKER_ALL_PARALLELISM`. Локальний агрегат за замовчуванням припиняє планувати нові pooled lanes після першого збою, а кожна смуга має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Смуги, чутливі до запуску або провайдера, виконуються ексклюзивно після паралельного пулу. Повторно використовуваний live/E2E workflow віддзеркалює шаблон shared-image: він збирає й публікує один SHA-tagged GHCR Docker E2E image перед Docker matrix, а потім запускає матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований live/E2E workflow щодня запускає повний release-path Docker suite. QR і installer Docker-тести зберігають власні Dockerfile, зосереджені на інсталяції. Окреме завдання `docker-e2e-fast` запускає обмежений Docker-профіль bundled-plugin з тайм-аутом команди 120 секунд: repair залежностей setup-entry плюс ізоляція синтетичного збою bundled-loader. Повна bundled update/channel matrix залишається ручною/для повного набору, оскільки виконує повторні реальні проходи npm update і doctor repair.
|
||||
Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покрита юніт-тестами в `src/scripts/ci-changed-scope.test.ts`.
|
||||
Зміни в workflow CI перевіряють граф Node CI плюс lint workflow, але самі по собі не примушують виконувати нативні збірки Windows, Android або macOS; ці платформні смуги залишаються прив’язаними до змін у вихідному коді відповідних платформ.
|
||||
Перевірки Windows Node обмежені специфічними для Windows обгортками процесів/шляхів, допоміжними засобами запуску npm/pnpm/UI runner, конфігурацією менеджера пакунків і поверхнями workflow CI, які виконують цю смугу; не пов’язані зміни у вихідному коді, plugin, install-smoke і зміни лише в тестах залишаються в Linux Node lanes, щоб не резервувати Windows worker на 16 vCPU для покриття, яке вже виконується звичайними тестовими шардами.
|
||||
Окремий workflow `install-smoke` повторно використовує той самий скрипт області дії через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, релевантних встановленню, пакуванню, контейнерам, production changes у bundled extension, а також для поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke jobs. Зміни лише в тестах і лише в документації не резервують Docker workers. Його smoke для QR package примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тому інсталяція все одно перевіряється без повторного завантаження залежностей під час кожного запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в межах цього завдання, тому додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки. Локальна команда `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image `scripts/e2e/Dockerfile`, а потім паралельно запускає live/E2E smoke lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте типову паралельність 4 через `OPENCLAW_DOCKER_ALL_PARALLELISM`. Локальний агрегатор типово припиняє планувати нові pooled lanes після першої помилки, а кожна смуга має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Смуги, чутливі до запуску або провайдера, виконуються ексклюзивно після паралельного пулу. Багаторазово використовуваний workflow live/E2E відтворює шаблон shared-image: спочатку збирає і публікує один Docker E2E image із тегом SHA у GHCR перед матрицею Docker, а потім запускає матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований workflow live/E2E щодня запускає повний Docker-набір для release-path. Тести QR та installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Окреме завдання `docker-e2e-fast` запускає обмежений Docker-профіль bundled-plugin з тайм-аутом команди 120 секунд: repair залежностей setup-entry плюс ізоляція синтетичної помилки bundled-loader. Повна матриця bundled update/channel залишається ручною/для повного набору, оскільки вона виконує повторні реальні проходи npm update і doctor repair.
|
||||
|
||||
Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіше ставиться до архітектурних меж, ніж широка CI-область платформ: production-зміни в core запускають core prod typecheck плюс core-тести, зміни лише в core-тестах запускають лише core test typecheck/tests, production-зміни в extension запускають extension prod typecheck плюс extension-тести, а зміни лише в extension-тестах запускають лише extension test typecheck/tests. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extension, тому що extension залежать від цих core-контрактів. Зміни лише в release metadata під час version bump запускають цільові перевірки версії, конфігурації та root-залежностей. Невідомі зміни в root/config безпечно розширюються до всіх смуг.
|
||||
Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний gate суворіший щодо архітектурних меж, ніж широка платформа області дії CI: зміни production у core запускають перевірку типів core prod плюс тести core, зміни лише в тестах core запускають лише перевірку типів/тести core test, зміни production у extension запускають перевірку типів extension prod плюс тести extension, а зміни лише в тестах extension запускають лише перевірку типів/тести extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку до extension, оскільки extension залежать від цих контрактів core. Зміни лише в метаданих релізу з оновленням версій запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно призводять до запуску всіх смуг.
|
||||
|
||||
Для push матриця `checks` додає смугу `compat-node22`, яка виконується лише для push. Для pull request ця смуга пропускається, і матриця зосереджується на звичайних test/channel lanes.
|
||||
Для push матриця `checks` додає смугу `compat-node22`, яка запускається лише для push. Для pull request ця смуга пропускається, і матриця зосереджується на звичайних test/channel lanes.
|
||||
|
||||
Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожне завдання залишалося невеликим і не резервувало зайві ранери: channel contracts запускаються як три зважені шарди, bundled plugin tests балансуються між шістьма workers для extension, невеликі core unit lanes об’єднуються в пари, auto-reply працює на трьох збалансованих workers замість шести дрібних, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування зібраних артефактів. Широкі browser, QA, media і miscellaneous plugin tests використовують свої окремі конфігурації Vitest замість спільного plugin catch-all. Широка agents lane використовує спільний планувальник file-parallel Vitest, оскільки в ній домінують імпорт і планування, а не один повільний тестовий файл. `runtime-config` запускається разом із шардом infra core-runtime, щоб спільний runtime shard не утримував найдовший хвіст. `check-additional` тримає разом роботу package-boundary compile/canary і відокремлює runtime topology architecture від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи їхні старі назви перевірок як легковагі завдання-верифікатори та водночас уникаючи двох додаткових Blacksmith workers і другої черги споживачів артефактів.
|
||||
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane усе одно компілює цей flavor з прапорцями SMS/call-log BuildConfig, водночас уникаючи дубльованого пакування debug APK для кожного Android-релевантного push.
|
||||
`extension-fast` виконується лише для PR, оскільки push-запуски вже виконують повні шарди bundled plugin. Це дає швидкий зворотний зв’язок щодо змінених plugins під час review без резервування додаткового Blacksmith worker на `main` для покриття, яке вже є в `checks-node-extensions`.
|
||||
Найповільніші сімейства тестів Node розділено або збалансовано так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: контракти каналів запускаються як три зважені шарди, тести bundled plugin балансуються між шістьма workers extension, малі core unit lanes об’єднані в пари, auto-reply виконується на трьох збалансованих workers замість шести малих workers, а agentic gateway/plugin configs розподілено між наявними agentic Node jobs лише для вихідного коду, замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої спеціалізовані конфігурації Vitest замість спільного універсального набору plugin. Широка смуга agents використовує спільний планувальник file-parallel Vitest, оскільки в ній домінують імпорти/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із shard infra core-runtime, щоб спільний runtime shard не утримував хвіст виконання. `check-additional` тримає compile/canary роботу package-boundary разом і відокремлює runtime topology architecture від покриття gateway watch; shard boundary guard виконує свої малі незалежні guards паралельно в межах одного завдання. Gateway watch, channel tests і shard core support-boundary виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано, зберігаючи їхні старі назви перевірок як легкі завдання-верифікатори та уникаючи двох додаткових Blacksmith workers і другої черги споживачів артефактів.
|
||||
Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Варіант third-party не має окремого source set або manifest; його смуга юніт-тестів усе одно компілює цей flavor із прапорцями BuildConfig для SMS/call-log, водночас уникаючи дубльованого завдання пакування debug APK для кожного push, релевантного Android.
|
||||
`extension-fast` є лише для PR, оскільки push-запуски вже виконують повні шарди bundled plugin. Це зберігає швидкий зворотний зв’язок щодо змінених plugin для рев’ю, не резервуючи додатковий Blacksmith worker на `main` для покриття, яке вже є в `checks-node-extensions`.
|
||||
|
||||
GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані шардові перевірки використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні збої шард, але не стають у чергу після того, як увесь workflow уже був замінений новішим запуском.
|
||||
Ключ конкурентності CI версіонований (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати нові запуски на main.
|
||||
GitHub може позначати застарілі завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо лише найновіший запуск для того самого ref також не завершується помилкою. Агреговані shard-перевірки використовують `!cancelled() && always()`, щоб і далі повідомляти про звичайні помилки shard, але не ставали в чергу після того, як увесь workflow уже було витіснено новішим запуском.
|
||||
Ключ конкурентності CI має версію (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
|
||||
|
||||
## Ранери
|
||||
## Runners
|
||||
|
||||
| Ранер | Завдання |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, агреговані верифікатори Node-тестів, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди Linux Node-тестів, шарди bundled plugin tests, `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` |
|
||||
| Runner | Завдання |
|
||||
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегатори (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегатори `check-additional`, агрегатори-верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує Ubuntu на GitHub-hosted, щоб матриця Blacksmith могла стати в чергу раніше |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugin, `android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, так що 8 vCPU коштували дорожче, ніж дали виграш; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував дорожче, ніж давав виграш |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний варіант `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний варіант `macos-latest` |
|
||||
|
||||
## Локальні еквіваленти
|
||||
|
||||
```bash
|
||||
pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD
|
||||
pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane
|
||||
pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guards
|
||||
pnpm check:changed # розумний локальний gate: changed typecheck/lint/tests за boundary lane
|
||||
pnpm check # швидкий локальний gate: production tsgo + шардований lint + паралельні fast guards
|
||||
pnpm check:test-types
|
||||
pnpm check:timed # та сама перевірка з вимірюванням часу для кожного етапу
|
||||
pnpm check:timed # той самий gate із таймінгами для кожного етапу
|
||||
pnpm build:strict-smoke
|
||||
pnpm check:architecture
|
||||
pnpm test:gateway:watch-regression
|
||||
pnpm test # тести vitest
|
||||
pnpm test:channels
|
||||
pnpm test:contracts:channels
|
||||
pnpm check:docs # форматування документації + lint + перевірка зламаних посилань
|
||||
pnpm build # зібрати dist, коли важливі смуги CI artifact/build-smoke
|
||||
node scripts/ci-run-timings.mjs <run-id> # підсумувати загальний час, час у черзі й найповільніші завдання
|
||||
pnpm check:docs # форматування документації + lint + зламані посилання
|
||||
pnpm build # збирає dist, коли важливі смуги CI artifact/build-smoke
|
||||
node scripts/ci-run-timings.mjs <run-id> # підсумувати wall time, час у черзі та найповільніші завдання
|
||||
node scripts/ci-run-timings.mjs --recent 10 # порівняти нещодавні успішні запуски main CI
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue
Block a user