chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
e486adf1a1
commit
f7ea0e06be
174
docs/uk/ci.md
174
docs/uk/ci.md
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
@ -1,29 +1,25 @@
|
||||
---
|
||||
read_when:
|
||||
- Ви хочете використовувати GitHub Copilot як провайдера models
|
||||
- Вам потрібен потік `openclaw models auth login-github-copilot`
|
||||
summary: Увійти до GitHub Copilot з OpenClaw за допомогою device flow
|
||||
- Ви хочете використовувати GitHub Copilot як постачальника моделі
|
||||
- Вам потрібен процес `openclaw models auth login-github-copilot`
|
||||
summary: Увійдіть у GitHub Copilot з OpenClaw за допомогою device flow
|
||||
title: GitHub Copilot
|
||||
x-i18n:
|
||||
generated_at: "2026-04-23T21:06:03Z"
|
||||
generated_at: "2026-04-24T22:51:39Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 8b54a063e30e9202c6b9de35a1a3736ef8c36020296215491fb719afe73a0c3e
|
||||
source_hash: d21ef936578741fe458f50ca25034a71e4571ae1e873de5e6d71138a950f5d70
|
||||
source_path: providers/github-copilot.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
GitHub Copilot — це AI-помічник для кодування від GitHub. Він надає доступ до
|
||||
моделей Copilot для вашого облікового запису та плану GitHub. OpenClaw може
|
||||
використовувати Copilot як провайдера models двома різними способами.
|
||||
GitHub Copilot — це помічник для кодування зі штучним інтелектом від GitHub. Він надає доступ до моделей Copilot для вашого облікового запису GitHub і тарифного плану. OpenClaw може використовувати Copilot як постачальника моделі двома різними способами.
|
||||
|
||||
## Два способи використовувати Copilot в OpenClaw
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Вбудований провайдер (github-copilot)">
|
||||
Використовуйте нативний device-login flow, щоб отримати токен GitHub, а потім обмінювати його на
|
||||
API-токени Copilot під час роботи OpenClaw. Це **типовий** і найпростіший шлях,
|
||||
оскільки він не потребує VS Code.
|
||||
<Tab title="Вбудований постачальник (github-copilot)">
|
||||
Використовуйте нативний процес входу через device flow, щоб отримати токен GitHub, а потім обміняти його на токени API Copilot під час роботи OpenClaw. Це **типовий** і найпростіший шлях, оскільки він не потребує VS Code.
|
||||
|
||||
<Steps>
|
||||
<Step title="Запустіть команду входу">
|
||||
@ -31,15 +27,14 @@ GitHub Copilot — це AI-помічник для кодування від Git
|
||||
openclaw models auth login-github-copilot
|
||||
```
|
||||
|
||||
Вам буде запропоновано перейти за URL і ввести одноразовий код. Не закривайте
|
||||
термінал до завершення процесу.
|
||||
Вам буде запропоновано перейти за URL-адресою та ввести одноразовий код. Тримайте термінал відкритим, доки процес не завершиться.
|
||||
</Step>
|
||||
<Step title="Задайте типову модель">
|
||||
<Step title="Установіть типову модель">
|
||||
```bash
|
||||
openclaw models set github-copilot/claude-opus-4.7
|
||||
```
|
||||
|
||||
Або в config:
|
||||
Або в конфігурації:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -54,12 +49,10 @@ GitHub Copilot — це AI-помічник для кодування від Git
|
||||
</Tab>
|
||||
|
||||
<Tab title="Plugin Copilot Proxy (copilot-proxy)">
|
||||
Використовуйте розширення **Copilot Proxy** для VS Code як локальний bridge. OpenClaw звертається до
|
||||
ендпоінта `/v1` цього proxy і використовує список моделей, який ви там налаштуєте.
|
||||
Використовуйте розширення VS Code **Copilot Proxy** як локальний міст. OpenClaw звертається до endpoint `/v1` проксі та використовує список моделей, який ви там налаштовуєте.
|
||||
|
||||
<Note>
|
||||
Обирайте це, якщо ви вже використовуєте Copilot Proxy у VS Code або вам потрібно маршрутизувати
|
||||
через нього. Ви маєте ввімкнути plugin і підтримувати роботу розширення VS Code.
|
||||
Вибирайте цей варіант, якщо ви вже запускаєте Copilot Proxy у VS Code або вам потрібно маршрутизувати трафік через нього. Ви маєте ввімкнути Plugin і підтримувати роботу розширення VS Code.
|
||||
</Note>
|
||||
|
||||
</Tab>
|
||||
@ -69,76 +62,71 @@ GitHub Copilot — це AI-помічник для кодування від Git
|
||||
|
||||
| Прапорець | Опис |
|
||||
| -------------- | --------------------------------------------------- |
|
||||
| `--yes` | Пропустити запит підтвердження |
|
||||
| `--set-default` | Також застосувати рекомендовану типову модель провайдера |
|
||||
| `--yes` | Пропустити запит на підтвердження |
|
||||
| `--set-default` | Також застосувати рекомендовану типову модель постачальника |
|
||||
|
||||
```bash
|
||||
# Skip confirmation
|
||||
# Пропустити підтвердження
|
||||
openclaw models auth login-github-copilot --yes
|
||||
|
||||
# Login and set the default model in one step
|
||||
# Увійти та встановити типову модель за один крок
|
||||
openclaw models auth login --provider github-copilot --method device --set-default
|
||||
```
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Потрібен інтерактивний TTY">
|
||||
Device-login flow потребує інтерактивного TTY. Запускайте його безпосередньо в
|
||||
терміналі, а не в неінтерактивному скрипті чи CI pipeline.
|
||||
Процес входу через device flow вимагає інтерактивного TTY. Запускайте його безпосередньо в терміналі, а не в неінтерактивному скрипті чи CI-конвеєрі.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Доступність моделей залежить від вашого плану">
|
||||
Доступність моделей Copilot залежить від вашого плану GitHub. Якщо модель
|
||||
відхиляється, спробуйте інший ID (наприклад, `github-copilot/gpt-4.1`).
|
||||
<Accordion title="Доступність моделей залежить від вашого тарифного плану">
|
||||
Доступність моделей Copilot залежить від вашого тарифного плану GitHub. Якщо модель відхиляється, спробуйте інший ідентифікатор (наприклад, `github-copilot/gpt-4.1`).
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Вибір transport">
|
||||
ID моделей Claude автоматично використовують transport Anthropic Messages. Моделі GPT,
|
||||
o-series і Gemini залишають OpenAI Responses transport. OpenClaw
|
||||
вибирає правильний transport на основі model ref.
|
||||
<Accordion title="Вибір транспорту">
|
||||
Ідентифікатори моделей Claude автоматично використовують транспорт Anthropic Messages. Моделі GPT, o-series і Gemini зберігають транспорт OpenAI Responses. OpenClaw вибирає правильний транспорт на основі посилання на модель.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Порядок розв’язання змінних середовища">
|
||||
OpenClaw розв’язує auth Copilot зі змінних середовища в такому
|
||||
порядку пріоритету:
|
||||
<Accordion title="Сумісність запитів">
|
||||
OpenClaw надсилає для транспортів Copilot заголовки запитів у стилі Copilot IDE, включно з подальшими ходами tool-result і image. Він не вмикає continuation Responses на рівні постачальника для Copilot, якщо таку поведінку не було перевірено на API Copilot.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Порядок пріоритету змінних середовища">
|
||||
OpenClaw визначає автентифікацію Copilot зі змінних середовища в такому порядку пріоритету:
|
||||
|
||||
| Пріоритет | Змінна | Примітки |
|
||||
| --------- | -------------------- | -------------------------------- |
|
||||
| 1 | `COPILOT_GITHUB_TOKEN` | Найвищий пріоритет, специфічний для Copilot |
|
||||
| 1 | `COPILOT_GITHUB_TOKEN` | Найвищий пріоритет, специфічна для Copilot |
|
||||
| 2 | `GH_TOKEN` | Токен GitHub CLI (резервний варіант) |
|
||||
| 3 | `GITHUB_TOKEN` | Стандартний токен GitHub (найнижчий) |
|
||||
| 3 | `GITHUB_TOKEN` | Стандартний токен GitHub (найнижчий пріоритет) |
|
||||
|
||||
Коли задано кілька змінних, OpenClaw використовує ту, що має найвищий пріоритет.
|
||||
Device-login flow (`openclaw models auth login-github-copilot`) зберігає
|
||||
свій токен у сховищі auth profile і має пріоритет над усіма змінними
|
||||
середовища.
|
||||
Коли встановлено кілька змінних, OpenClaw використовує ту, що має найвищий пріоритет.
|
||||
Процес входу через device flow (`openclaw models auth login-github-copilot`) зберігає свій токен у сховищі профілів автентифікації та має пріоритет над усіма змінними середовища.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Зберігання токена">
|
||||
Під час входу токен GitHub зберігається в сховищі auth profile, а вже під час запуску OpenClaw він обмінюється
|
||||
на API-токен Copilot. Вам не потрібно керувати токеном вручну.
|
||||
Під час входу токен GitHub зберігається у сховищі профілів автентифікації та обмінюється на токен API Copilot під час роботи OpenClaw. Вам не потрібно керувати токеном вручну.
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
<Warning>
|
||||
Потрібен інтерактивний TTY. Запускайте команду входу безпосередньо в терміналі, а не
|
||||
в headless-скрипті чи CI job.
|
||||
Потрібен інтерактивний TTY. Запускайте команду входу безпосередньо в терміналі, а не всередині headless-скрипту чи CI-завдання.
|
||||
</Warning>
|
||||
|
||||
## Embeddings для пошуку пам’яті
|
||||
## Вбудовування для пошуку в пам’яті
|
||||
|
||||
GitHub Copilot також може слугувати провайдером embeddings для
|
||||
[пошуку пам’яті](/uk/concepts/memory-search). Якщо у вас є підписка Copilot і
|
||||
ви вже увійшли в систему, OpenClaw може використовувати його для embeddings без окремого API-ключа.
|
||||
GitHub Copilot також може слугувати постачальником вбудовувань для
|
||||
[пошуку в пам’яті](/uk/concepts/memory-search). Якщо у вас є підписка Copilot і
|
||||
ви виконали вхід, OpenClaw може використовувати його для вбудовувань без окремого API-ключа.
|
||||
|
||||
### Автовизначення
|
||||
### Автовиявлення
|
||||
|
||||
Коли `memorySearch.provider` має значення `"auto"` (типове), GitHub Copilot пробується
|
||||
з пріоритетом 15 — після локальних embeddings, але до OpenAI та інших платних
|
||||
провайдерів. Якщо доступний токен GitHub, OpenClaw виявляє доступні
|
||||
embedding-моделі через API Copilot і автоматично вибирає найкращу.
|
||||
Коли `memorySearch.provider` має значення `"auto"` (типове значення), GitHub Copilot
|
||||
пробується з пріоритетом 15 — після локальних вбудовувань, але перед OpenAI та іншими платними
|
||||
постачальниками. Якщо доступний токен GitHub, OpenClaw виявляє доступні
|
||||
моделі вбудовувань через API Copilot і автоматично вибирає найкращу.
|
||||
|
||||
### Явна config
|
||||
### Явна конфігурація
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -146,7 +134,7 @@ embedding-моделі через API Copilot і автоматично виби
|
||||
defaults: {
|
||||
memorySearch: {
|
||||
provider: "github-copilot",
|
||||
// Optional: override the auto-discovered model
|
||||
// Необов’язково: перевизначити модель, виявлену автоматично
|
||||
model: "text-embedding-3-small",
|
||||
},
|
||||
},
|
||||
@ -156,22 +144,22 @@ embedding-моделі через API Copilot і автоматично виби
|
||||
|
||||
### Як це працює
|
||||
|
||||
1. OpenClaw розв’язує ваш токен GitHub (зі змінних env або auth profile).
|
||||
2. Обмінює його на короткоживучий API-токен Copilot.
|
||||
3. Опитує ендпоінт Copilot `/models`, щоб виявити доступні embedding-моделі.
|
||||
1. OpenClaw визначає ваш токен GitHub (зі змінних середовища або профілю автентифікації).
|
||||
2. Обмінює його на короткоживучий токен API Copilot.
|
||||
3. Виконує запит до endpoint `/models` Copilot, щоб виявити доступні моделі вбудовувань.
|
||||
4. Вибирає найкращу модель (надає перевагу `text-embedding-3-small`).
|
||||
5. Надсилає запити на embeddings до ендпоінта Copilot `/embeddings`.
|
||||
5. Надсилає запити на вбудовування до endpoint `/embeddings` Copilot.
|
||||
|
||||
Доступність моделей залежить від вашого плану GitHub. Якщо embedding-моделей
|
||||
немає, OpenClaw пропускає Copilot і пробує наступного провайдера.
|
||||
Доступність моделей залежить від вашого тарифного плану GitHub. Якщо моделі
|
||||
вбудовувань недоступні, OpenClaw пропускає Copilot і переходить до наступного постачальника.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Вибір моделі" href="/uk/concepts/model-providers" icon="layers">
|
||||
Вибір провайдерів, посилань на моделі та поведінки failover.
|
||||
Вибір постачальників, посилань на моделі та поведінки резервного перемикання.
|
||||
</Card>
|
||||
<Card title="OAuth і auth" href="/uk/gateway/authentication" icon="key">
|
||||
Деталі auth і правила повторного використання credentials.
|
||||
<Card title="OAuth і автентифікація" href="/uk/gateway/authentication" icon="key">
|
||||
Докладніше про автентифікацію та правила повторного використання облікових даних.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
@ -4,48 +4,48 @@ read_when:
|
||||
summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage
|
||||
title: Тести
|
||||
x-i18n:
|
||||
generated_at: "2026-04-24T19:52:49Z"
|
||||
generated_at: "2026-04-24T22:51:37Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 4393562f7ab8471d44ab1573bc14b041fb50058bfc61de628e02328793193ed7
|
||||
source_hash: f15e68a95d68dd076862aa168a836c4918876afa1f925ed183f7fde8ec75f24a
|
||||
source_path: reference/test.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
- Повний набір для тестування (набори, live, Docker): [Testing](/uk/help/testing)
|
||||
- Повний набір для тестування (сьюти, live, Docker): [Тестування](/uk/help/testing)
|
||||
|
||||
- `pnpm test:force`: завершує будь-який завислий процес gateway, що утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
|
||||
- `pnpm test:coverage`: запускає unit-набір із V8 coverage (через `vitest.unit.config.ts`). Це перевірка unit coverage для завантажених файлів, а не coverage всіх файлів у всьому репозиторії. Пороги становлять 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit coverage, замість того щоб вважати непокритими всі файли вихідного коду з розділених lane-ів.
|
||||
- `pnpm test:coverage:changed`: запускає unit coverage лише для файлів, змінених відносно `origin/main`.
|
||||
- `pnpm test:changed`: розгортає змінені git-шляхи у scoped Vitest lane-и, коли diff зачіпає лише routable файли вихідного коду/тестів. Зміни config/setup, як і раніше, повертаються до нативного запуску root projects, щоб зміни в wiring за потреби повторно запускали ширший набір.
|
||||
- `pnpm changed:lanes`: показує архітектурні lane-и, активовані diff-ом відносно `origin/main`.
|
||||
- `pnpm check:changed`: запускає розумну перевірку changed gate для diff-а відносно `origin/main`. Вона запускає core-роботи з core test lane-ами, роботу extensions — з extension test lane-ами, зміни лише в тестах — тільки з test typecheck/tests, розширює зміни в публічному SDK Plugin-ів або plugin-contract до одного проходу валідації extensions і залишає version bumps лише в release metadata на цільових перевірках version/config/root-dependency.
|
||||
- `pnpm test`: маршрутизує явні цілі file/directory через scoped Vitest lane-и. Запуски без цілі використовують фіксовані shard-групи та розгортаються до leaf config-ів для локального паралельного виконання; група extensions завжди розгортається до shard config-ів для кожного extension/plugin, а не до одного великого процесу root-project.
|
||||
- Повні запуски та shard-запуски extensions оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці таймінги для балансування повільних і швидких shard-ів. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів.
|
||||
- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane-и, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі випадки на їхніх наявних lane-ах.
|
||||
- Вибрані файли вихідного коду helper-ів `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, тож невеликі правки helper-ів не спричиняють повторного запуску важких наборів із підтримкою runtime.
|
||||
- `auto-reply` тепер також розділено на три окремі config-и (`core`, `top-level`, `reply`), тож harness reply не домінує над легшими тестами top-level status/token/helper.
|
||||
- Базовий config Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний non-isolated runner увімкнено в config-ах репозиторію.
|
||||
- `pnpm test:force`: Завершує будь-який завислий процес gateway, який утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
|
||||
- `pnpm test:coverage`: Запускає набір unit-тестів з V8 coverage (через `vitest.unit.config.ts`). Це перевірка unit coverage для завантажених файлів, а не coverage всіх файлів у всьому репозиторії. Порогові значення: 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit coverage, замість того щоб вважати кожен файл вихідного коду з розбитих lane непокритим.
|
||||
- `pnpm test:coverage:changed`: Запускає unit coverage лише для файлів, змінених відносно `origin/main`.
|
||||
- `pnpm test:changed`: розгортає змінені git-шляхи у scoped lane Vitest, коли diff зачіпає лише routable файли коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску root project, щоб за потреби правки wiring перезапускали ширший набір.
|
||||
- `pnpm changed:lanes`: показує архітектурні lane, які запускаються diff відносно `origin/main`.
|
||||
- `pnpm check:changed`: запускає розумну changed-перевірку для diff відносно `origin/main`. Вона запускає core-роботи з lane core-тестів, extension-роботи з lane extension-тестів, test-only зміни лише з test typecheck/tests, розширює зміни публічного Plugin SDK або plugin-contract до одного проходу валідації extension і залишає підвищення версій лише в release metadata на цільових перевірках version/config/root-dependency.
|
||||
- `pnpm test`: маршрутизує явні цілі файлів/каталогів через scoped lane Vitest. Запуски без цілей використовують фіксовані shard-групи та розгортаються до leaf configs для локального паралельного виконання; група extension завжди розгортається до per-extension shard config, а не до одного великого процесу root project.
|
||||
- Повні запуски та запуски shard extension оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці таймінги для балансування повільних і швидких shard. Встановіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів.
|
||||
- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі випадки у наявних lane.
|
||||
- Вибрані допоміжні файли коду `plugin-sdk` і `commands` також відображають `pnpm test:changed` на явні сусідні тести в цих легких lane, тому невеликі правки helper не змушують перезапускати важкі набори з підтримкою runtime.
|
||||
- `auto-reply` тепер також розбивається на три окремі config (`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` і `pnpm test extensions` запускають усі shard-и extensions/Plugin-ів. Важкі channel Plugin-и, browser Plugin і OpenAI запускаються як окремі shard-и; інші групи Plugin-ів залишаються пакетованими. Використовуйте `pnpm test extensions/<id>` для одного lane вбудованого Plugin-а.
|
||||
- `pnpm test:perf:imports`: вмикає звітність Vitest про import-duration + import-breakdown, водночас зберігаючи scoped lane routing для явних цілей file/directory.
|
||||
- `pnpm test:perf:imports:changed`: те саме профілювання import-ів, але лише для файлів, змінених відносно `origin/main`.
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` виконує benchmark маршрутизованого шляху в режимі changed проти нативного запуску root-project для того самого закоміченого git diff-а.
|
||||
- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel plugins, browser plugin і OpenAI запускаються як окремі shard; інші групи plugin залишаються згрупованими. Використовуйте `pnpm test extensions/<id>` для однієї bundled lane plugin.
|
||||
- `pnpm test:perf:imports`: вмикає звітність Vitest про тривалість імпорту та деталізацію імпорту, при цьому все ще використовує маршрутизацію scoped lane для явних цілей файлів/каталогів.
|
||||
- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`.
|
||||
- `pnpm test:perf:changed:bench -- --ref <git-ref>` виконує benchmark маршрутизованого шляху changed-mode проти нативного запуску root project для того самого закоміченого git diff.
|
||||
- `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного набору змін у worktree без попереднього коміту.
|
||||
- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`).
|
||||
- `pnpm test:perf:profile:runner`: записує CPU + heap profiles для unit runner-а (`.artifacts/vitest-runner-profile`).
|
||||
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожен leaf config Vitest повного набору й записує згруповані дані тривалості разом з JSON/log артефактами для кожного config-а. Агент продуктивності тестів використовує це як базову лінію перед спробами виправити повільні тести.
|
||||
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після зміни, зосередженої на продуктивності.
|
||||
- Інтеграція Gateway: opt-in через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
|
||||
- `pnpm test:e2e`: запускає smoke-тести gateway end-to-end (multi-instance WS/HTTP/node pairing). Типово використовує `threads` + `isolate: false` з адаптивними worker-ами у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановлюйте `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
|
||||
- `pnpm test:live`: запускає live-тести провайдерів (minimax/zai). Потребує API-ключів і `LIVE=1` (або специфічного для провайдера `*_LIVE_TEST=1`) для зняття пропуску.
|
||||
- `pnpm test:docker:all`: один раз збирає спільний image для live-тестів і Docker E2E image, а потім запускає Docker smoke lane-и з `OPENCLAW_SKIP_DOCKER_BUILD=1` через weighted scheduler. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` керує слотами процесів і типово дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` керує tail pool, чутливим до провайдерів, і також типово дорівнює 10. Обмеження важких lane-ів типово становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; для потужніших хостів використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT`. Запуски lane-ів за замовчуванням зсуваються на 2 секунди, щоб уникнути локальних піків створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner припиняє планувати нові pooled lane-и після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожен lane має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Логи для кожного lane-а записуються в `.artifacts/docker-tests/<run-id>/`.
|
||||
- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім виконує реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live model (наприклад, OpenAI у `~/.profile`), завантажує зовнішній image Open WebUI і не очікується як CI-стабільний, на відміну від звичайних unit/e2e наборів.
|
||||
- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із початковим наповненням і другий контейнер клієнта, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутованих розмов, читання транскриптів, метадані вкладень, поведінку черги live events, маршрутизацію вихідних надсилань і сповіщення про канал + дозволи в стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-кадри напряму, щоб smoke-тест відображав те, що міст реально надсилає.
|
||||
- `pnpm test:perf:profile:runner`: записує CPU + heap profiles для unit runner (`.artifacts/vitest-runner-profile`).
|
||||
- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожну leaf config Vitest повного набору та записує згруповані дані тривалості разом з JSON/log-артефактами для кожної config. Агент продуктивності тестів використовує це як базову лінію перед спробами виправлення повільних тестів.
|
||||
- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після змін, спрямованих на продуктивність.
|
||||
- Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
|
||||
- `pnpm test:e2e`: Запускає smoke-тести gateway end-to-end (pairing кількох екземплярів WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю worker у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
|
||||
- `pnpm test:live`: Запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або провайдер-специфічний `*_LIVE_TEST=1`) для зняття пропуску.
|
||||
- `pnpm test:docker:all`: Один раз збирає спільний образ live-тестів і образ Docker E2E, а потім запускає Docker smoke lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` через зважений планувальник. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` керує кількістю слотів процесів і за замовчуванням дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` керує чутливим до провайдера tail pool і за замовчуванням теж дорівнює 10. Обмеження для важких lane за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=4` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=5`; використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` для більших хостів. Запуски lane за замовчуванням відтерміновуються на 2 секунди, щоб уникати локальних сплесків створення контейнерів у Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner за замовчуванням виконує попередню перевірку Docker, очищує застарілі контейнери OpenClaw E2E, виводить статус активних lane кожні 30 секунд і зберігає таймінги lane у `.artifacts/docker-tests/lane-timings.json` для впорядкування за принципом longest-first у наступних запусках. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб вивести manifest lane без запуску Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` для налаштування виводу статусу або `OPENCLAW_DOCKER_ALL_TIMINGS=0`, щоб вимкнути повторне використання таймінгів. Runner припиняє планувати нові pooled lane після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а кожна lane має резервний timeout у 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; окремі live/tail lane використовують жорсткіші ліміти для кожної lane. Логи для кожної lane записуються в `.artifacts/docker-tests/<run-id>/`.
|
||||
- `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 event queue, маршрутизацію outbound send і сповіщення каналу + дозволів у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає необроблені stdio MCP frames безпосередньо, щоб smoke відображав те, що міст реально надсилає.
|
||||
|
||||
## Локальний PR gate
|
||||
## Локальна PR-перевірка
|
||||
|
||||
Для локальних перевірок перед приземленням PR/gate запускайте:
|
||||
Для локальних перевірок перед злиттям/гейтом PR запустіть:
|
||||
|
||||
- `pnpm check:changed`
|
||||
- `pnpm check`
|
||||
@ -54,12 +54,12 @@ x-i18n:
|
||||
- `pnpm test`
|
||||
- `pnpm check:docs`
|
||||
|
||||
Якщо `pnpm test` дає flaky-результат на навантаженому хості, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте через `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`
|
||||
|
||||
## Benchmark затримки моделей (локальні ключі)
|
||||
## Benchmark затримки моделі (локальні ключі)
|
||||
|
||||
Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
|
||||
|
||||
@ -67,7 +67,7 @@ x-i18n:
|
||||
|
||||
- `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
|
||||
- Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
|
||||
- Типова підказка: “Reply with a single word: ok. No punctuation or extra text.”
|
||||
- Типовий prompt: “Reply with a single word: ok. No punctuation or extra text.”
|
||||
|
||||
Останній запуск (2025-12-31, 20 запусків):
|
||||
|
||||
@ -95,31 +95,31 @@ 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-и:
|
||||
Набори 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`: обидва набори preset
|
||||
|
||||
Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8 profiles для кожного запуску, тому захоплення таймінгів і profiles використовує той самий harness.
|
||||
Вивід включає `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення максимального 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` оновлює fixture baseline, що зберігається в репозиторії, у `test/fixtures/cli-startup-bench.json`, використовуючи `runs=5` і `warmup=1`
|
||||
- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з використанням `runs=5` і `warmup=1`
|
||||
|
||||
Fixture, що зберігається в репозиторії:
|
||||
Fixture, закомічений у репозиторій:
|
||||
|
||||
- `test/fixtures/cli-startup-bench.json`
|
||||
- Оновлення через `pnpm test:startup:bench:update`
|
||||
- Порівняння поточних результатів із fixture через `pnpm test:startup:bench:check`
|
||||
- Оновіть через `pnpm test:startup:bench:update`
|
||||
- Порівняйте поточні результати з fixture через `pnpm test:startup:bench:check`
|
||||
|
||||
## Onboarding E2E (Docker)
|
||||
## E2E онбордингу (Docker)
|
||||
|
||||
Docker необов’язковий; це потрібно лише для containerized smoke-тестів onboarding.
|
||||
Docker необов’язковий; це потрібно лише для containerized smoke-тестів онбордингу.
|
||||
|
||||
Повний cold-start flow у чистому Linux-контейнері:
|
||||
Повний потік cold-start у чистому Linux-контейнері:
|
||||
|
||||
```bash
|
||||
scripts/e2e/onboard-docker.sh
|
||||
@ -127,9 +127,9 @@ scripts/e2e/onboard-docker.sh
|
||||
|
||||
Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, а потім запускає gateway і виконує `openclaw health`.
|
||||
|
||||
## Smoke-тест імпорту QR (Docker)
|
||||
## Smoke для QR import (Docker)
|
||||
|
||||
Гарантує, що підтримуваний runtime helper для QR завантажується в підтримуваних Docker Node runtime-ах (Node 24 за замовчуванням, Node 22 сумісний):
|
||||
Переконується, що підтримуваний helper runtime для QR завантажується в підтримуваних Node runtime у Docker (Node 24 за замовчуванням, Node 22 сумісний):
|
||||
|
||||
```bash
|
||||
pnpm test:docker:qr
|
||||
@ -137,5 +137,5 @@ pnpm test:docker:qr
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Testing](/uk/help/testing)
|
||||
- [Testing live](/uk/help/testing-live)
|
||||
- [Тестування](/uk/help/testing)
|
||||
- [Live-тестування](/uk/help/testing-live)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user