chore(i18n): refresh uk translations

This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-20 14:54:51 +00:00
parent d29c4cc292
commit 4cb81e2554
3 changed files with 512 additions and 490 deletions

View File

@ -1,57 +1,59 @@
---
read_when:
- Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
- Ви налагоджуєте збої перевірок GitHub Actions
summary: Граф завдань CI, обмежувальні перевірки за областю змін і локальні еквіваленти команд
- Ви налагоджуєте невдалі перевірки GitHub Actions
summary: Граф завдань CI, межі перевірок і локальні еквіваленти команд
title: Конвеєр CI
x-i18n:
generated_at: "2026-04-20T14:13:25Z"
generated_at: "2026-04-20T14:50:26Z"
model: gpt-5.4
provider: openai
source_hash: dd4ffb6986739ee6f4fca6e8b1f40baee7e47a8387e8d06c722881ebe78b4766
source_hash: 69056ef80de9f1744b4a8ad71c0a8927307430defa2b8a21a8613525e9c5ac18
source_path: ci.md
workflow: 15
---
# Конвеєр CI
CI запускається для кожного push до `main` і для кожного pull request. Він використовує розумне обмеження за областю змін, щоб пропускати дорогі завдання, коли змінено лише непов’язані частини.
CI запускається для кожного push до `main` і для кожного pull request. Він використовує розумне визначення меж, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки.
## Огляд завдань
| Завдання | Призначення | Коли запускається |
| ------------------------ | ----------------------------------------------------------------------------------------- | ------------------------------------ |
| `preflight` | Визначає зміни лише в документації, змінені області, змінені розширення та збирає маніфест CI | Завжди для push і PR, що не є draft |
| `security-fast` | Виявлення приватних ключів, аудит workflow через `zizmor`, аудит production-залежностей | Завжди для push і PR, що не є draft |
| `build-artifacts` | Збирає `dist/` і Control UI один раз, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node |
| `checks-fast-core` | Швидкі Linux-перевірки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node |
| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень | Зміни, релевантні для Node |
| `checks-node-core-test` | Шарди основних Node-тестів, без channel, bundled, contract і extension-ланів | Зміни, релевантні для Node |
| `extension-fast` | Сфокусовані тести лише для змінених bundled plugins | Коли виявлено зміни розширень |
| `check` | Основна локальна перевірка в CI: `pnpm check`, `pnpm check:test-types` і `pnpm build:strict-smoke` | Зміни, релевантні для Node |
| `check-additional` | Перевірки архітектури, меж, циклів імпорту, а також regression harness для gateway watch | Зміни, релевантні для Node |
| `build-smoke` | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску | Зміни, релевантні для Node |
| `checks` | Решта Linux Node-ланів: channel-тести та сумісність лише для 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 | Зміни, релевантні для Android |
| Завдання | Призначення | Коли запускається |
| ------------------------ | ------------------------------------------------------------------------------------------ | ----------------------------------- |
| `preflight` | Визначає зміни лише в документації, змінені межі, змінені extensions і збирає маніфест CI | Завжди для push і PR, що не є draft |
| `security-fast` | Виявлення приватних ключів, аудит workflow через `zizmor`, аудит production-залежностей | Завжди для push і PR, що не є draft |
| `build-artifacts` | Один раз збирає `dist/` і Control UI, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node |
| `checks-fast-core` | Швидкі Linux-перевірки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node |
| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору extension | Зміни, релевантні для Node |
| `checks-node-core-test` | Шарди core Node tests, за винятком channel, bundled, contract і extension lanes | Зміни, релевантні для Node |
| `extension-fast` | Сфокусовані тести лише для змінених bundled plugins | Коли виявлено зміни в extension |
| `check` | Основна локальна перевірка в CI: `pnpm check`, `pnpm check:test-types` і `pnpm build:strict-smoke` | Зміни, релевантні для Node |
| `check-additional` | Захист архітектури, меж і import-cycle плюс regression harness для gateway watch | Зміни, релевантні для Node |
| `build-smoke` | Smoke-тести зібраного CLI і smoke-тест стартового використання пам’яті | Зміни, релевантні для Node |
| `checks` | Решта Linux Node lanes: channel tests і лише для push сумісність Node 22 | Зміни, релевантні для Node |
| `check-docs` | Перевірки форматування документації, lint і битих посилань | Змінено документацію |
| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python Skills |
| `checks-windows` | Специфічні для Windows test lanes | Зміни, релевантні для Windows |
| `macos-node` | Лінія TypeScript-тестів на macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS |
| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS |
| `android` | Матриця збірки й тестів Android | Зміни, релевантні для Android |
## Порядок Fail-Fast
Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
Завдання впорядковано так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускатимуться дорогі:
1. `preflight` вирішує, які лани взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
2. `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань з артефактами та матрицями платформ.
3. `build-artifacts` виконується паралельно зі швидкими Linux-ланами, щоб downstream-споживачі могли почати роботу, щойно буде готова спільна збірка.
4. Після цього розгалужуються важчі платформні та runtime-лани: `checks-fast-core`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
2. `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань матриці артефактів і платформ.
3. `build-artifacts` виконується паралельно зі швидкими Linux-лініями, щоб downstream-споживачі могли почати роботу щойно буде готова спільна збірка.
4. Після цього розгалужуються важчі платформні й runtime-лінії: `checks-fast-core`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
Логіка обмеження за областю змін знаходиться в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
Окремий workflow `install-smoke` повторно використовує той самий скрипт областей через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу `changed-smoke`, тому Docker/install smoke запускається лише для змін, пов’язаних зі встановленням, пакуванням і контейнерами.
Логіка меж розташована в `scripts/ci-changed-scope.mjs` і покривається unit tests у `src/scripts/ci-changed-scope.test.ts`.
Окремий workflow `install-smoke` повторно використовує той самий скрипт меж через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, релевантних встановленню, пакуванню й контейнерам.
Для push матриця `checks` додає лан `compat-node22`, який запускається лише для push. Для pull request цей лан пропускається, і матриця зосереджується на звичайних тестових/channel-ланах.
Логіка локальних changed-lane розміщена в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широкі платформні межі CI: зміни в core production запускають typecheck core prod плюс core tests, зміни лише в core tests запускають лише typecheck/tests для core tests, зміни в extension production запускають typecheck extension prod плюс extension tests, а зміни лише в extension tests запускають лише typecheck/tests для extension tests. Зміни в публічному Plugin SDK або plugin-contract розширюють перевірку на extension, оскільки extensions залежать від цих core-контрактів. Невідомі зміни в корені/конфігурації з міркувань безпеки запускають усі лінії.
Для push матриця `checks` додає лінію `compat-node22`, яка запускається лише для push. Для pull request цю лінію пропускають, і матриця залишається зосередженою на звичайних test/channel lanes.
## Runners
@ -64,14 +66,16 @@ CI запускається для кожного push до `main` і для к
## Локальні еквіваленти
```bash
pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі перевірки
pnpm changed:lanes # перевірити локальний класифікатор changed-lane для origin/main...HEAD
pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane
pnpm check # швидка локальна перевірка: production tsgo + shard-ований lint + паралельні швидкі захисні перевірки
pnpm check:test-types
pnpm check:timed # та сама перевірка з помітками часу для кожного етапу
pnpm check:timed # та сама перевірка з вимірюванням часу для кожного етапу
pnpm build:strict-smoke
pnpm check:architecture
pnpm test:gateway:watch-regression
pnpm test # vitest-тести
pnpm test:channels
pnpm check:docs # форматування документації + lint + биті посилання
pnpm build # збірка dist, коли важливі CI-лани artifact/build-smoke
pnpm check:docs # форматування документації + lint + перевірка битих посилань
pnpm build # збірка dist, коли важливі лінії CI artifact/build-smoke
```

File diff suppressed because it is too large Load Diff

View File

@ -1,76 +1,79 @@
---
read_when:
- Запуск або виправлення тестів
summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage
summary: Як локально запускати тести (`vitest`) і коли використовувати режими force/coverage
title: Тести
x-i18n:
generated_at: "2026-04-20T14:13:23Z"
generated_at: "2026-04-20T14:50:23Z"
model: gpt-5.4
provider: openai
source_hash: 03c44e5e4fab11883d9af416141d3e8013360a46b7c201ad9ac7cee5e6b3d24e
source_hash: 60eac73850ec1b573113a89b9f9a75079b963a1dcd0f774d96e68b08b29f221d
source_path: reference/test.md
workflow: 15
---
# Тести
- Повний набір для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing)
- Повний набір для тестування (сьюти, live, Docker): [Тестування](/uk/help/testing)
- `pnpm test:force`: Завершує будь-який завислий процес gateway, що утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
- `pnpm test:coverage`: Запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для рядків/гілок/функцій/інструкцій. Із покриття виключені entrypoint-и з важкою інтеграцією (CLI wiring, мости gateway/telegram, статичний сервер webchat), щоб ціль залишалася зосередженою на логіці, придатній для unit-тестування.
- `pnpm test:coverage:changed`: Запускає покриття unit-тестів лише для файлів, змінених відносно `origin/main`.
- `pnpm test:changed`: розгортає змінені git-шляхи в обмежені lane-и Vitest, коли diff торкається лише routable файлів source/test. Зміни конфігурації/налаштування все ще повертаються до нативного запуску root projects, тож зміни wiring за потреби повторно запускаються ширше.
- `pnpm test`: спрямовує явні цілі файлів/каталогів через обмежені lane-и Vitest. Нетаргетовані запуски тепер виконують одинадцять послідовних shard-конфігурацій (`vitest.full-core-unit-src.config.ts`, `vitest.full-core-unit-security.config.ts`, `vitest.full-core-unit-ui.config.ts`, `vitest.full-core-unit-support.config.ts`, `vitest.full-core-support-boundary.config.ts`, `vitest.full-core-contracts.config.ts`, `vitest.full-core-bundled.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного гігантського процесу root-project.
- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі lane-и, які залишають лише `test/setup.ts`, а runtime-важкі випадки — у наявних lane-ах.
- Вибрані вихідні helper-файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, тож невеликі зміни helper-ів не змушують повторно запускати важкі набори з підтримкою runtime.
- `auto-reply` тепер також поділяється на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness для reply не домінував над легшими тестами статусу/token/helper верхнього рівня.
- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` та `isolate: false`, із увімкненим спільним неізольованим runner-ом у всіх конфігураціях репозиторію.
- `pnpm test:force`: завершує будь-який завислий процес gateway, який утримує стандартний контрольний порт, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
- `pnpm test:coverage`: запускає набір unit-тестів з V8 coverage (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для lines/branches/functions/statements. Coverage виключає точки входу з важкою інтеграцією (обв’язка CLI, мости gateway/telegram, статичний сервер webchat), щоб зосередити ціль на логіці, придатній для unit-тестування.
- `pnpm test:coverage:changed`: запускає unit coverage лише для файлів, змінених відносно `origin/main`.
- `pnpm test:changed`: розгортає змінені git-шляхи в scoped-режими Vitest, коли diff торкається лише routable файлів source/test. Зміни config/setup, як і раніше, повертаються до нативного запуску root projects, щоб зміни в обв’язці за потреби перезапускали ширший набір.
- `pnpm changed:lanes`: показує архітектурні режими, які спрацьовують для diff відносно `origin/main`.
- `pnpm check:changed`: запускає розумну перевірку changed для diff відносно `origin/main`. Вона запускає core-роботи з core test lanes, роботу extensions — з extension test lanes, зміни лише в тестах — тільки з test typecheck/tests, а також розширює зміни публічного Plugin SDK або plugin-contract до валідації extensions.
- `pnpm test`: спрямовує явні цілі file/directory через scoped-режими Vitest. Ненацілені запуски тепер виконують одинадцять послідовних shard-конфігів (`vitest.full-core-unit-src.config.ts`, `vitest.full-core-unit-security.config.ts`, `vitest.full-core-unit-ui.config.ts`, `vitest.full-core-unit-support.config.ts`, `vitest.full-core-support-boundary.config.ts`, `vitest.full-core-contracts.config.ts`, `vitest.full-core-bundled.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного гігантського процесу root-project.
- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі режими, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі випадки у їхніх наявних режимах.
- Вибрані вихідні helper-файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких режимах, щоб невеликі зміни helper-файлів не спричиняли повторний запуск важких наборів із backing runtime.
- `auto-reply` тепер також розділено на три окремі конфіги (`core`, `top-level`, `reply`), щоб harness для reply не домінував над легшими top-level тестами status/token/helper.
- Базовий конфіг Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх конфігах репозиторію.
- `pnpm test:channels` запускає `vitest.channels.config.ts`.
- `pnpm test:extensions` запускає `vitest.extensions.config.ts`.
- `pnpm test:extensions`: запускає набори розширень/Plugin-ів.
- `pnpm test:perf:imports`: вмикає звітність Vitest щодо тривалості імпорту та розбивки імпортів, при цьому для явних цілей файлів/каталогів усе ще використовується спрямування через обмежені lane-и.
- `pnpm test:perf:imports:changed`: те саме профілювання імпортів, але лише для файлів, змінених відносно `origin/main`.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` виконує бенчмарк спрямованого режиму changed-mode проти нативного запуску root-project для того самого закоміченого git diff.
- `pnpm test:perf:changed:bench -- --worktree` виконує бенчмарк поточного набору змін робочого дерева без попереднього коміту.
- `pnpm test:extensions`: запускає набори extension/plugin.
- `pnpm test:perf:imports`: вмикає звітність Vitest щодо тривалості імпорту та import-breakdown, і водночас використовує маршрутизацію scoped-режимів для явних цілей file/directory.
- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`.
- `pnpm test:perf:changed:bench -- --ref <git-ref>` вимірює продуктивність маршрутизованого changed-режиму порівняно з нативним запуском root-project для того самого закоміченого git diff.
- `pnpm test:perf:changed:bench -- --worktree` вимірює продуктивність поточного набору змін у worktree без попереднього коміту.
- `pnpm test:perf:profile:main`: записує CPU-профіль для головного потоку Vitest (`.artifacts/vitest-main-profile`).
- `pnpm test:perf:profile:runner`: записує CPU- та heap-профілі для unit runner-а (`.artifacts/vitest-runner-profile`).
- `pnpm test:perf:profile:runner`: записує CPU- і heap-профілі для unit runner (`.artifacts/vitest-runner-profile`).
- Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (парування multi-instance WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановлюйте `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
- `pnpm test:live`: запускає live-тести provider-ів (minimax/zai). Потребує API-ключів і `LIVE=1` (або специфічного для provider `*_LIVE_TEST=1`) для зняття пропуску.
- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім виконує реальний проксійований чат через `/api/chat/completions`. Потребує придатного live-ключа моделі (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не розрахований на таку стабільність у CI, як звичайні набори unit/e2e.
- `pnpm test:docker:mcp-channels`: запускає seeded контейнер Gateway і другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані attachment, поведінку черги live-подій, маршрутизацію вихідного надсилання та сповіщення про channel + permission у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі кадри stdio MCP безпосередньо, тож smoke відповідає тому, що міст реально надсилає.
- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (multi-instance WS/HTTP/node pairing). Типово використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=<n>`, а для докладних логів установіть `OPENCLAW_E2E_VERBOSE=1`.
- `pnpm test:live`: запускає live-тести provider’ів (minimax/zai). Потребує API-ключів і `LIVE=1` (або provider-specific `*_LIVE_TEST=1`) для зняття skip.
- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live-моделі (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не вважається таким стабільним для CI, як звичайні набори unit/e2e.
- `pnpm test:docker:mcp-channels`: запускає seeded-контейнер Gateway і другий контейнер клієнта, який запускає `openclaw mcp serve`, а потім перевіряє routed discovery розмов, читання transcript, metadata вкладень, поведінку черги live-подій, outbound send routing, а також сповіщення про channel + permission у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-кадри безпосередньо, щоб smoke-тест відображав те, що міст реально надсилає.
## Локальний PR gate
## Локальна PR-перевірка
Для локальних перевірок перед злиттям/пропуском PR виконайте:
Для локальних перевірок перед злиттям PR запускайте:
- `pnpm check:changed`
- `pnpm check`
- `pnpm check:test-types`
- `pnpm build`
- `pnpm test`
- `pnpm check:docs`
Якщо `pnpm test` дає нестабільний збій на навантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
Якщо `pnpm test` дає flaky-результат на навантаженій машині, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте проблему через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
- `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
- `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
## Бенч латентності моделі (локальні ключі)
## Bench затримки моделей (локальні ключі)
Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
Використання:
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
- Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
- Типовий prompt: “Reply with a single word: ok. No punctuation or extra text.”
- Необов’язкові змінні середовища: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
- Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків чи додаткового тексту.”
Останній запуск (2025-12-31, 20 запусків):
- minimax median 1279ms (min 1114, max 2431)
- opus median 2454ms (min 1224, max 3170)
## Бенч запуску CLI
## Bench запуску CLI
Скрипт: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
@ -91,19 +94,19 @@ x-i18n:
- `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
- `pnpm tsx scripts/bench-cli-startup.ts --json`
Набори preset-ів:
Пресети:
- `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
- `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
- `all`: обидва набори preset-ів
- `all`: обидва пресети
Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8-профілі для кожного запуску, щоб вимірювання часу та збирання профілів використовували один і той самий harness.
Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і підсумки max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8-профілі для кожного запуску, щоб заміри часу й зняття профілів виконувалися тим самим harness.
Угоди щодо збереженого виводу:
- `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json`
- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json`, використовуючи `runs=5` і `warmup=1`
- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json`, використовуючи `runs=5` і `warmup=1`
- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з `runs=5` і `warmup=1`
- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з `runs=5` і `warmup=1`
Закомічений fixture:
@ -115,17 +118,17 @@ x-i18n:
Docker необов’язковий; це потрібно лише для containerized smoke-тестів onboarding.
Повний cold-start flow у чистому Linux-контейнері:
Повний cold-start потік у чистому Linux-контейнері:
```bash
scripts/e2e/onboard-docker.sh
```
Цей скрипт проводить інтерактивний майстер через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
## Smoke-тест імпорту QR (Docker)
Гарантує, що `qrcode-terminal` завантажується у підтримуваних Docker runtime Node (типово Node 24, сумісно з Node 22):
Гарантує, що `qrcode-terminal` завантажується в підтримуваних Docker runtime Node (Node 24 типово, Node 22 сумісний):
```bash
pnpm test:docker:qr