chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
8b978d8a4c
commit
873c3eaf85
@ -3,13 +3,13 @@ read_when:
|
||||
- Ви хочете безпечно оновити робочу копію вихідного коду
|
||||
- Ви налагоджуєте вивід або параметри `openclaw update`
|
||||
- Потрібно розуміти поведінку скороченого запису `--update`
|
||||
summary: Довідка CLI для `openclaw update` (відносно безпечне оновлення джерела + автоматичний перезапуск Gateway)
|
||||
title: Оновлення
|
||||
summary: Довідник CLI для `openclaw update` (відносно безпечне оновлення джерела + автоматичний перезапуск Gateway)
|
||||
title: Оновити
|
||||
x-i18n:
|
||||
generated_at: "2026-05-03T20:54:32Z"
|
||||
generated_at: "2026-05-04T20:59:55Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 53ec06b8db5e2aba4000922f92a36834e8782986a77f6b5889bb19031a59f1b8
|
||||
source_hash: b12b1837ae80a3688fb7805d78d5a354f07dccdaba175cfa429e18145e543a1f
|
||||
source_path: cli/update.md
|
||||
workflow: 16
|
||||
---
|
||||
@ -18,7 +18,8 @@ x-i18n:
|
||||
|
||||
Безпечно оновлюйте OpenClaw і перемикайтеся між каналами stable/beta/dev.
|
||||
|
||||
Якщо ви встановили через **npm/pnpm/bun** (глобальне встановлення, без метаданих git), оновлення виконуються через потік пакетного менеджера в [Оновлення](/uk/install/updating).
|
||||
Якщо ви встановили через **npm/pnpm/bun** (глобальне встановлення, без метаданих git),
|
||||
оновлення відбуваються через потік менеджера пакетів, описаний у [Оновлення](/uk/install/updating).
|
||||
|
||||
## Використання
|
||||
|
||||
@ -39,25 +40,31 @@ openclaw --update
|
||||
|
||||
## Параметри
|
||||
|
||||
- `--no-restart`: пропустити перезапуск служби Gateway після успішного оновлення. Оновлення через пакетний менеджер, які перезапускають Gateway, перевіряють, що перезапущена служба повідомляє очікувану оновлену версію, перш ніж команда завершиться успішно.
|
||||
- `--channel <stable|beta|dev>`: задати канал оновлень (git + npm; зберігається в конфігурації).
|
||||
- `--tag <dist-tag|version|spec>`: перевизначити ціль пакета лише для цього оновлення. Для встановлень пакета `main` зіставляється з `github:openclaw/openclaw#main`.
|
||||
- `--no-restart`: пропустити перезапуск служби Gateway після успішного оновлення. Оновлення через менеджер пакетів, які перезапускають Gateway, перевіряють, що перезапущена служба повідомляє очікувану оновлену версію, перш ніж команда завершиться успішно.
|
||||
- `--channel <stable|beta|dev>`: установити канал оновлення (git + npm; зберігається в конфігурації).
|
||||
- `--tag <dist-tag|version|spec>`: перевизначити ціль пакета лише для цього оновлення. Для встановлень пакетів `main` відповідає `github:openclaw/openclaw#main`.
|
||||
- `--dry-run`: попередньо переглянути заплановані дії оновлення (канал/тег/ціль/потік перезапуску) без запису конфігурації, встановлення, синхронізації plugins або перезапуску.
|
||||
- `--json`: вивести машинозчитуваний JSON `UpdateRunResult`, зокрема
|
||||
`postUpdate.plugins.integrityDrifts`, коли під час синхронізації Plugin після оновлення
|
||||
виявлено дрейф артефактів npm Plugin.
|
||||
- `--timeout <seconds>`: тайм-аут для кожного кроку (типово 1800с).
|
||||
- `--yes`: пропустити запити підтвердження (наприклад, підтвердження повернення до старішої версії).
|
||||
`postUpdate.plugins.integrityDrifts`, коли під час післяоновлювальної синхронізації plugins
|
||||
виявлено розбіжність артефактів npm plugin.
|
||||
- `--timeout <seconds>`: тайм-аут для кожного кроку (типово 1800 с).
|
||||
- `--yes`: пропустити запити підтвердження (наприклад, підтвердження зниження версії).
|
||||
|
||||
`openclaw update` не має прапорця `--verbose`. Використовуйте `--dry-run`, щоб попередньо переглянути заплановані дії каналу/тега/встановлення/перезапуску, `--json` для машинозчитуваних результатів і `openclaw update status --json`, коли потрібні лише відомості про канал і доступність. Якщо ви налагоджуєте журнали Gateway під час оновлення, докладність консолі та рівень файлових журналів є окремими: Gateway `--verbose` впливає на вивід термінала/WebSocket, тоді як файлові журнали потребують `logging.level: "debug"` або `"trace"` у конфігурації. Див. [Журналювання Gateway](/uk/gateway/logging).
|
||||
`openclaw update` не має прапорця `--verbose`. Використовуйте `--dry-run`, щоб попередньо переглянути
|
||||
заплановані дії каналу/тега/встановлення/перезапуску, `--json` для машинозчитуваних
|
||||
результатів і `openclaw update status --json`, коли потрібні лише канал і
|
||||
відомості про доступність. Якщо ви налагоджуєте журнали Gateway під час оновлення,
|
||||
докладність консолі та рівень файлового журналу налаштовуються окремо: Gateway `--verbose` впливає
|
||||
на вивід термінала/WebSocket, тоді як для файлових журналів потрібні `logging.level: "debug"` або
|
||||
`"trace"` у конфігурації. Див. [Журналювання Gateway](/uk/gateway/logging).
|
||||
|
||||
<Warning>
|
||||
Повернення до старіших версій потребує підтвердження, бо старіші версії можуть пошкодити конфігурацію.
|
||||
Зниження версії потребує підтвердження, оскільки старіші версії можуть порушити конфігурацію.
|
||||
</Warning>
|
||||
|
||||
## `update status`
|
||||
|
||||
Показати активний канал оновлень + тег/гілку/SHA git (для checkout вихідного коду), а також доступність оновлення.
|
||||
Показати активний канал оновлення + тег/гілку/SHA git (для checkout вихідного коду), а також доступність оновлення.
|
||||
|
||||
```bash
|
||||
openclaw update status
|
||||
@ -68,12 +75,12 @@ openclaw update status --timeout 10
|
||||
Параметри:
|
||||
|
||||
- `--json`: вивести машинозчитуваний JSON стану.
|
||||
- `--timeout <seconds>`: тайм-аут для перевірок (типово 3с).
|
||||
- `--timeout <seconds>`: тайм-аут для перевірок (типово 3 с).
|
||||
|
||||
## `update wizard`
|
||||
|
||||
Інтерактивний потік для вибору каналу оновлень і підтвердження, чи перезапускати Gateway
|
||||
після оновлення (типово перезапускати). Якщо ви виберете `dev` без git checkout, він
|
||||
Інтерактивний потік для вибору каналу оновлення та підтвердження, чи перезапускати Gateway
|
||||
після оновлення (типово перезапускати). Якщо вибрати `dev` без git checkout, він
|
||||
запропонує створити його.
|
||||
|
||||
Параметри:
|
||||
@ -85,111 +92,112 @@ openclaw update status --timeout 10
|
||||
Коли ви явно перемикаєте канали (`--channel ...`), OpenClaw також підтримує
|
||||
узгодженість методу встановлення:
|
||||
|
||||
- `dev` → забезпечує git checkout (типово: `~/openclaw`, перевизначення через `OPENCLAW_GIT_DIR`),
|
||||
- `dev` → забезпечує git checkout (типово: `~/openclaw`, перевизначається через `OPENCLAW_GIT_DIR`),
|
||||
оновлює його та встановлює глобальний CLI з цього checkout.
|
||||
- `stable` → встановлює з npm за допомогою `latest`.
|
||||
- `beta` → віддає перевагу dist-tag npm `beta`, але повертається до `latest`, коли beta
|
||||
відсутня або старіша за поточний стабільний випуск.
|
||||
- `beta` → надає перевагу npm dist-tag `beta`, але повертається до `latest`, коли beta
|
||||
відсутній або старіший за поточний stable-випуск.
|
||||
|
||||
Автооновлювач ядра Gateway (коли ввімкнений у конфігурації) запускає шлях оновлення CLI
|
||||
поза активним обробником запитів Gateway. Оновлення `update.run` пакетного менеджера
|
||||
через control plane примусово виконують невідкладний перезапуск після заміни пакета,
|
||||
без періоду охолодження, бо старий процес Gateway може ще мати фрагменти в пам'яті,
|
||||
які вказують на файли, вилучені новим пакетом.
|
||||
Автооновлювач ядра Gateway (коли ввімкнений через конфігурацію) запускає шлях оновлення CLI
|
||||
поза активним обробником запитів Gateway. Оновлення через менеджер пакетів control-plane `update.run`
|
||||
примусово виконують невідкладений перезапуск оновлення без періоду очікування після заміни пакета,
|
||||
оскільки старий процес Gateway усе ще може мати в памʼяті фрагменти, що вказують на
|
||||
файли, вилучені новим пакетом.
|
||||
|
||||
Для встановлень через пакетний менеджер `openclaw update` визначає цільову версію
|
||||
пакета перед викликом пакетного менеджера. Глобальні встановлення npm використовують
|
||||
поетапне встановлення: OpenClaw встановлює новий пакет у тимчасовий npm prefix, перевіряє
|
||||
Для встановлень через менеджер пакетів `openclaw update` визначає цільову версію
|
||||
пакета перед викликом менеджера пакетів. Глобальні встановлення npm використовують поетапне
|
||||
встановлення: OpenClaw встановлює новий пакет у тимчасовий префікс npm, перевіряє
|
||||
там інвентар упакованого `dist`, а потім замінює це чисте дерево пакета в
|
||||
справжньому глобальному prefix. Якщо перевірка не вдається, post-update doctor, синхронізація Plugin і
|
||||
робота з перезапуском не виконуються з підозрілого дерева. Навіть коли встановлена версія
|
||||
вже збігається з цільовою, команда оновлює глобальне встановлення пакета,
|
||||
а потім виконує синхронізацію Plugin, оновлення завершення основної команди та роботу з перезапуском. Це
|
||||
підтримує узгодженість упакованих допоміжних компонентів і записів Plugin, що належать каналу, з
|
||||
установленою збіркою OpenClaw, залишаючи повне перебудування завершень команд Plugin для
|
||||
реальному глобальному префіксі. Якщо перевірка не вдається, післяоновлювальний doctor, синхронізація plugin і
|
||||
перезапуск не виконуються з підозрілого дерева. Навіть коли встановлена версія
|
||||
вже відповідає цілі, команда оновлює глобальне встановлення пакета,
|
||||
а потім виконує синхронізацію plugin, оновлення завершень основних команд і перезапуск. Це
|
||||
підтримує узгодженість упакованих sidecar-компонентів і записів plugins, керованих каналом, з
|
||||
установленою збіркою OpenClaw, залишаючи повні перебудови завершень команд plugins для
|
||||
явних запусків `openclaw completion --write-state`.
|
||||
|
||||
Коли встановлена локальна керована служба Gateway і перезапуск увімкнено,
|
||||
оновлення через пакетний менеджер зупиняють запущену службу перед заміною дерева пакета,
|
||||
потім оновлюють метадані служби з оновленого встановлення, перезапускають
|
||||
Коли встановлено локальну керовану службу Gateway і перезапуск увімкнено,
|
||||
оновлення через менеджер пакетів зупиняють запущену службу перед заміною дерева
|
||||
пакета, потім оновлюють метадані служби з оновленого встановлення, перезапускають
|
||||
службу та перевіряють, що перезапущений Gateway повідомляє очікувану версію, перш ніж
|
||||
повідомити про успіх. На macOS перевірка після оновлення також перевіряє, що LaunchAgent
|
||||
завантажено/запущено для активного профілю, а налаштований порт loopback
|
||||
справний. Якщо plist встановлено, але launchd не наглядає за ним, OpenClaw
|
||||
автоматично повторно bootstrap LaunchAgent, а потім знову виконує
|
||||
перевірки готовності health/version/channel. Свіжий bootstrap завантажує завдання RunAtLoad
|
||||
напряму, тож відновлення після оновлення не виконує негайно `kickstart -k` для щойно
|
||||
створеного Gateway. Якщо Gateway і далі не стає справним, команда завершується
|
||||
з ненульовим кодом і друкує шлях до журналу перезапуску, а також явні інструкції щодо перезапуску, перевстановлення та
|
||||
повідомити про успіх. На macOS післяоновлювальна перевірка також підтверджує, що LaunchAgent
|
||||
завантажений/запущений для активного профілю, а налаштований порт loopback
|
||||
справний. Якщо plist встановлено, але launchd не керує ним, OpenClaw
|
||||
автоматично повторно завантажує LaunchAgent, а потім повторно виконує
|
||||
перевірки готовності стану/версії/каналу. Свіже завантаження напряму завантажує завдання RunAtLoad,
|
||||
тому відновлення після оновлення не виконує негайно `kickstart -k` для щойно
|
||||
запущеного Gateway. Якщо Gateway усе ще не стає справним, команда завершується
|
||||
з ненульовим кодом і виводить шлях до журналу перезапуску, а також явні інструкції щодо перезапуску, перевстановлення та
|
||||
відкату пакета. З `--no-restart`
|
||||
заміна пакета все одно виконується, але керована служба не зупиняється й не
|
||||
перезапускається, тому запущений Gateway може зберігати старий код, доки ви не перезапустите його
|
||||
заміна пакета все одно виконується, але керована служба не зупиняється і не
|
||||
перезапускається, тому запущений Gateway може використовувати старий код, доки ви не перезапустите його
|
||||
вручну.
|
||||
|
||||
## Потік git checkout
|
||||
|
||||
### Вибір каналу
|
||||
|
||||
- `stable`: checkout найновішого не-beta тега, потім build і doctor.
|
||||
- `beta`: віддати перевагу найновішому тегу `-beta`, але повернутися до найновішого stable тега, коли beta відсутня або старіша.
|
||||
- `stable`: checkout останнього не-beta тегу, потім збірка й doctor.
|
||||
- `beta`: надати перевагу останньому тегу `-beta`, але повернутися до останнього stable тегу, коли beta відсутній або старіший.
|
||||
- `dev`: checkout `main`, потім fetch і rebase.
|
||||
|
||||
### Кроки оновлення
|
||||
|
||||
<Steps>
|
||||
<Step title="Перевірити чистий worktree">
|
||||
<Step title="Verify clean worktree">
|
||||
Потребує відсутності незакомічених змін.
|
||||
</Step>
|
||||
<Step title="Перемкнути канал">
|
||||
<Step title="Switch channel">
|
||||
Перемикає на вибраний канал (тег або гілку).
|
||||
</Step>
|
||||
<Step title="Отримати upstream">
|
||||
Лише dev.
|
||||
<Step title="Fetch upstream">
|
||||
Лише для dev.
|
||||
</Step>
|
||||
<Step title="Передпольотна збірка (лише dev)">
|
||||
<Step title="Preflight build (dev only)">
|
||||
Запускає lint і збірку TypeScript у тимчасовому worktree. Якщо tip не проходить, відступає назад до 10 комітів, щоб знайти найновішу чисту збірку.
|
||||
</Step>
|
||||
<Step title="Rebase">
|
||||
Виконує rebase на вибраний коміт (лише dev).
|
||||
</Step>
|
||||
<Step title="Встановити залежності">
|
||||
Використовує пакетний менеджер репозиторію. Для pnpm checkout оновлювач bootstrap `pnpm` на вимогу (спершу через `corepack`, потім тимчасовий fallback `npm install pnpm@10`) замість запуску `npm run build` усередині pnpm workspace.
|
||||
<Step title="Install dependencies">
|
||||
Використовує менеджер пакетів репозиторію. Для pnpm checkout оновлювач завантажує `pnpm` на вимогу (спершу через `corepack`, потім як fallback тимчасовий `npm install pnpm@10`) замість запуску `npm run build` усередині pnpm workspace.
|
||||
</Step>
|
||||
<Step title="Зібрати Control UI">
|
||||
<Step title="Build Control UI">
|
||||
Збирає gateway і Control UI.
|
||||
</Step>
|
||||
<Step title="Запустити doctor">
|
||||
<Step title="Run doctor">
|
||||
`openclaw doctor` запускається як фінальна перевірка безпечного оновлення.
|
||||
</Step>
|
||||
<Step title="Синхронізувати plugins">
|
||||
Синхронізує plugins з активним каналом. Dev використовує bundled plugins; stable і beta використовують npm. Оновлює відстежувані встановлення Plugin.
|
||||
<Step title="Sync plugins">
|
||||
Синхронізує plugins з активним каналом. Dev використовує bundled plugins; stable і beta використовують npm. Оновлює відстежувані встановлення plugins.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
На каналі оновлень beta відстежувані встановлення npm і ClawHub Plugin, що слідують
|
||||
лінії default/latest, спершу пробують випуск Plugin `@beta`. Якщо Plugin не має
|
||||
beta-випуску, OpenClaw повертається до записаної специфікації default/latest. Точні
|
||||
версії та явні теги не переписуються.
|
||||
На каналі оновлення beta відстежувані встановлення npm і ClawHub plugins, що йдуть
|
||||
лінією default/latest, спочатку пробують випуск plugin `@beta`. Якщо plugin не має
|
||||
beta-випуску, OpenClaw повертається до записаної специфікації default/latest. Для npm
|
||||
plugins OpenClaw також повертається назад, коли beta-пакет існує, але не проходить
|
||||
перевірку встановлення. Точні версії та явні теги не переписуються.
|
||||
|
||||
<Warning>
|
||||
Якщо оновлення точно закріпленого npm Plugin визначає артефакт, цілісність якого відрізняється від збереженого запису встановлення, `openclaw update` перериває це оновлення артефакта Plugin замість його встановлення. Перевстановлюйте або явно оновлюйте Plugin лише після перевірки, що ви довіряєте новому артефакту.
|
||||
Якщо оновлення точно закріпленого npm plugin визначає артефакт, цілісність якого відрізняється від збереженого запису встановлення, `openclaw update` перериває оновлення цього артефакту plugin замість його встановлення. Перевстановіть або оновіть plugin явно лише після того, як переконаєтеся, що довіряєте новому артефакту.
|
||||
</Warning>
|
||||
|
||||
<Note>
|
||||
Збої синхронізації Plugin після оновлення призводять до збою результату оновлення та зупиняють подальшу роботу з перезапуском. Виправте помилку встановлення або оновлення Plugin, потім повторно запустіть `openclaw update`.
|
||||
Збої післяоновлювальної синхронізації plugin призводять до невдалого результату оновлення та зупиняють подальший перезапуск. Виправте помилку встановлення або оновлення plugin, потім повторно запустіть `openclaw update`.
|
||||
|
||||
Коли оновлений Gateway запускається, завантаження Plugin працює лише в режимі перевірки: startup не запускає пакетні менеджери й не змінює дерева залежностей. Перезапуски `update.run` пакетного менеджера обходять звичайне idle deferral і restart cooldown після заміни дерева пакета, тож старий процес не може продовжувати ледаче завантаження вилучених фрагментів.
|
||||
Коли оновлений Gateway запускається, завантаження plugin є лише перевіркою: запуск не виконує менеджери пакетів і не змінює дерева залежностей. Перезапуски `update.run` через менеджер пакетів обходять звичайне відкладення через бездіяльність і період очікування перезапуску після заміни дерева пакета, тому старий процес не може продовжувати ліниво завантажувати вилучені фрагменти.
|
||||
|
||||
Якщо pnpm bootstrap усе ще завершується помилкою, оновлювач зупиняється рано з помилкою, специфічною для пакетного менеджера, замість спроби `npm run build` усередині checkout.
|
||||
Якщо початкове завантаження pnpm усе ще не вдається, оновлювач зупиняється рано з помилкою, специфічною для менеджера пакетів, замість спроби виконати `npm run build` усередині checkout.
|
||||
</Note>
|
||||
|
||||
## Скорочення `--update`
|
||||
|
||||
`openclaw --update` переписується на `openclaw update` (корисно для оболонок і launcher scripts).
|
||||
`openclaw --update` переписується на `openclaw update` (корисно для shell-оболонок і launcher-скриптів).
|
||||
|
||||
## Пов'язане
|
||||
## Пов’язане
|
||||
|
||||
- `openclaw doctor` (пропонує спершу запустити оновлення для git checkout)
|
||||
- `openclaw doctor` (пропонує спочатку запустити оновлення для git checkout)
|
||||
- [Канали розробки](/uk/install/development-channels)
|
||||
- [Оновлення](/uk/install/updating)
|
||||
- [Довідник CLI](/uk/cli)
|
||||
|
||||
@ -2,48 +2,50 @@
|
||||
read_when:
|
||||
- Зміна поведінки оновлення OpenClaw, doctor, приймання пакета або встановлення Plugin
|
||||
- Підготовка або затвердження реліз-кандидата
|
||||
- Налагодження регресій оновлення пакета, очищення залежностей Plugin або встановлення Plugin
|
||||
- Налагодження оновлення пакета, очищення залежностей Plugin або регресій встановлення Plugin
|
||||
sidebarTitle: Update and plugin tests
|
||||
summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення/оновлення Plugin
|
||||
title: 'Тестування: оновлення та Plugins'
|
||||
title: 'Тестування: оновлення та плагіни'
|
||||
x-i18n:
|
||||
generated_at: "2026-05-03T08:23:00Z"
|
||||
generated_at: "2026-05-04T21:00:01Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 309ac7785a8d49db241989d28580887d3f6739982108af7148b624082c5f23dd
|
||||
source_hash: e83a847c76f424199b5fccbd9a2b30d0bf01e4f466c4f9822bf7693d1c2ad286
|
||||
source_path: help/testing-updates-plugins.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Це спеціальний контрольний список для перевірки оновлень і Plugin. Мета
|
||||
проста: довести, що встановлюваний пакет може оновлювати реальний стан користувача, виправляти застарілий
|
||||
legacy-стан через `doctor` і досі встановлювати, завантажувати, оновлювати та видаляти
|
||||
Plugin із підтримуваних джерел.
|
||||
проста: довести, що інстальований пакет може оновлювати реальний стан
|
||||
користувача, відновлювати застарілий legacy-стан через `doctor` і далі
|
||||
встановлювати, завантажувати, оновлювати та видаляти Plugin з підтримуваних
|
||||
джерел.
|
||||
|
||||
Для ширшої мапи засобу запуску тестів див. [Тестування](/uk/help/testing). Для live-ключів провайдерів
|
||||
і наборів тестів, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live).
|
||||
Ширшу мапу тестового runner див. у [Тестування](/uk/help/testing). Для ключів
|
||||
live provider і suite, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live).
|
||||
|
||||
## Що ми захищаємо
|
||||
|
||||
Тести оновлень і Plugin захищають ці контракти:
|
||||
Тести оновлень і Plugin захищають такі контракти:
|
||||
|
||||
- Tarball пакета є повним, має валідний `dist/postinstall-inventory.json`
|
||||
і не залежить від розпакованих файлів репозиторію.
|
||||
- Користувач може перейти зі старішого опублікованого пакета на пакет-кандидат
|
||||
без втрати конфігурації, агентів, сесій, робочих просторів, allowlist Plugin або
|
||||
конфігурації каналу.
|
||||
- `openclaw doctor --fix --non-interactive` володіє шляхами очищення та виправлення
|
||||
legacy-стану. Startup не має розростатися прихованими міграціями сумісності для застарілого
|
||||
стану Plugin.
|
||||
- Встановлення Plugin працює з локальних каталогів, git-репозиторіїв, npm-пакетів і
|
||||
шляху реєстру ClawHub.
|
||||
- Tarball пакета є повним, має чинний `dist/postinstall-inventory.json` і не
|
||||
залежить від розпакованих файлів репозиторію.
|
||||
- Користувач може перейти зі старішого опублікованого пакета на кандидатний
|
||||
пакет без втрати config, agents, sessions, workspaces, allowlist Plugin або
|
||||
config каналів.
|
||||
- `openclaw doctor --fix --non-interactive` володіє шляхами legacy-очищення та
|
||||
відновлення. Startup не має нарощувати приховані compatibility-міграції для
|
||||
застарілого стану Plugin.
|
||||
- Встановлення Plugin працює з локальних директорій, git repo, npm packages і
|
||||
шляху registry ClawHub.
|
||||
- npm-залежності Plugin встановлюються в керований npm root, скануються перед
|
||||
довірою і видаляються через npm під час видалення, щоб hoisted-залежності не
|
||||
довірою та видаляються через npm під час uninstall, щоб hoisted залежності не
|
||||
залишалися.
|
||||
- Оновлення Plugin стабільне, коли нічого не змінилося: записи встановлення, resolved
|
||||
source, структура встановлених залежностей і enabled-стан залишаються неушкодженими.
|
||||
- Оновлення Plugin стабільне, коли нічого не змінилося: install records,
|
||||
resolved source, installed dependency layout і enabled state залишаються
|
||||
незмінними.
|
||||
|
||||
## Локальний доказ під час розробки
|
||||
## Локальне підтвердження під час розробки
|
||||
|
||||
Починайте вузько:
|
||||
|
||||
@ -53,30 +55,32 @@ pnpm check:changed
|
||||
pnpm test:changed
|
||||
```
|
||||
|
||||
Для змін установлення, видалення, залежностей Plugin або package-inventory також
|
||||
запустіть сфокусовані тести, що покривають змінений seam:
|
||||
Для змін у install, uninstall, залежностях або package-inventory Plugin також
|
||||
запускайте сфокусовані тести, що покривають відредагований seam:
|
||||
|
||||
```bash
|
||||
pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
|
||||
```
|
||||
|
||||
Перш ніж будь-яка package Docker lane використає tarball, доведіть артефакт пакета:
|
||||
Перед тим як будь-яка package Docker lane споживатиме tarball, підтвердьте
|
||||
артефакт пакета:
|
||||
|
||||
```bash
|
||||
pnpm release:check
|
||||
```
|
||||
|
||||
`release:check` запускає перевірки drift для конфігурації/документації/API, записує package dist
|
||||
inventory, запускає `npm pack --dry-run`, відхиляє заборонені запаковані файли, встановлює
|
||||
tarball у тимчасовий prefix, запускає postinstall і smoke-тестує bundled entrypoints каналів.
|
||||
`release:check` запускає перевірки drift config/docs/API, записує package dist
|
||||
inventory, виконує `npm pack --dry-run`, відхиляє заборонені packed files,
|
||||
встановлює tarball у тимчасовий prefix, запускає postinstall і smoke-тестує
|
||||
entrypoints bundled channel.
|
||||
|
||||
## Docker lanes
|
||||
|
||||
Docker lanes є доказом рівня продукту. Вони встановлюють або оновлюють реальний
|
||||
пакет усередині Linux-контейнерів і перевіряють поведінку через CLI-команди,
|
||||
запуск Gateway, HTTP-зонди, RPC-статус і стан файлової системи.
|
||||
Docker lanes є підтвердженням на рівні продукту. Вони встановлюють або
|
||||
оновлюють реальний пакет у Linux containers і перевіряють поведінку через CLI
|
||||
commands, startup Gateway, HTTP probes, RPC status і filesystem state.
|
||||
|
||||
Використовуйте сфокусовані lanes під час ітерацій:
|
||||
Під час ітерацій використовуйте сфокусовані lanes:
|
||||
|
||||
```bash
|
||||
pnpm test:docker:plugins
|
||||
@ -89,32 +93,32 @@ pnpm test:docker:update-migration
|
||||
|
||||
Важливі lanes:
|
||||
|
||||
- `test:docker:plugins` перевіряє plugin install smoke, встановлення локальних папок,
|
||||
skip-поведінку оновлення локальних папок, локальні папки з попередньо встановленими
|
||||
залежностями, встановлення `file:`-пакетів, git-встановлення з виконанням CLI, оновлення git
|
||||
moving-ref, встановлення з npm-реєстру з hoisted transitive
|
||||
dependencies, no-op оновлення npm, встановлення з локального ClawHub fixture та no-op
|
||||
оновлення, поведінку marketplace update і enable/inspect для Claude-bundle. Встановіть
|
||||
`OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub залишався hermetic/offline.
|
||||
- `test:docker:plugin-lifecycle-matrix` встановлює пакет-кандидат у чистому
|
||||
контейнері, проводить npm Plugin через install, inspect, disable, enable,
|
||||
- `test:docker:plugins` перевіряє smoke install Plugin, installs local folder,
|
||||
поведінку skip для update local folder, local folders із попередньо
|
||||
встановленими залежностями, installs `file:` package, git installs із CLI
|
||||
execution, git moving-ref updates, npm registry installs із hoisted transitive
|
||||
dependencies, no-op для npm update, installs local ClawHub fixture і no-op
|
||||
update, поведінку marketplace update і Claude-bundle enable/inspect. Задайте
|
||||
`OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub був hermetic/offline.
|
||||
- `test:docker:plugin-lifecycle-matrix` встановлює candidate package у bare
|
||||
container, проганяє npm Plugin через install, inspect, disable, enable,
|
||||
explicit upgrade, explicit downgrade і uninstall після видалення коду Plugin.
|
||||
Він логує RSS і CPU-метрики для кожної фази.
|
||||
- `test:docker:plugin-update` перевіряє, що незмінений установлений Plugin
|
||||
не перевстановлюється і не втрачає metadata встановлення під час `openclaw plugins update`.
|
||||
- `test:docker:upgrade-survivor` встановлює tarball-кандидат поверх брудного
|
||||
old-user fixture, запускає package update плюс non-interactive doctor, потім запускає
|
||||
local loopback Gateway і перевіряє збереження стану.
|
||||
- `test:docker:published-upgrade-survivor` спершу встановлює опублікований baseline,
|
||||
налаштовує його через baked recipe `openclaw config set`, оновлює його до
|
||||
tarball-кандидата, запускає doctor, перевіряє legacy cleanup, запускає Gateway і
|
||||
зондує `/healthz`, `/readyz` і RPC-статус.
|
||||
- `test:docker:update-migration` — cleanup-heavy lane опублікованого оновлення. Вона
|
||||
стартує з налаштованого Discord/Telegram-style стану користувача, запускає baseline
|
||||
doctor, щоб налаштовані залежності Plugin мали шанс матеріалізуватися, сідує
|
||||
legacy plugin dependency debris для налаштованого packaged Plugin, оновлює до
|
||||
tarball-кандидата і вимагає від post-update doctor видалити legacy
|
||||
dependency roots.
|
||||
Він логуватиме RSS і CPU metrics для кожної фази.
|
||||
- `test:docker:plugin-update` перевіряє, що незмінений встановлений Plugin не
|
||||
перевстановлюється і не втрачає install metadata під час `openclaw plugins update`.
|
||||
- `test:docker:upgrade-survivor` встановлює candidate tarball поверх dirty
|
||||
old-user fixture, запускає package update плюс non-interactive doctor, потім
|
||||
стартує Gateway на loopback і перевіряє збереження стану.
|
||||
- `test:docker:published-upgrade-survivor` спочатку встановлює published
|
||||
baseline, налаштовує його через baked recipe `openclaw config set`, оновлює
|
||||
до candidate tarball, запускає doctor, перевіряє legacy cleanup, стартує
|
||||
Gateway і пробує `/healthz`, `/readyz` та RPC status.
|
||||
- `test:docker:update-migration` є cleanup-heavy published-update lane. Він
|
||||
стартує з налаштованого користувацького стану у стилі Discord/Telegram,
|
||||
запускає baseline doctor, щоб configured plugin dependencies мали шанс
|
||||
матеріалізуватися, сіє legacy plugin dependency debris для configured
|
||||
packaged Plugin, оновлює до candidate tarball і вимагає, щоб post-update
|
||||
doctor видалив legacy dependency roots.
|
||||
|
||||
Корисні варіанти published-upgrade survivor:
|
||||
|
||||
@ -129,15 +133,15 @@ pnpm test:docker:published-upgrade-survivor
|
||||
```
|
||||
|
||||
Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`,
|
||||
`plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і
|
||||
`versioned-runtime-deps`. В aggregate runs,
|
||||
`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі reported
|
||||
issue-shaped сценарії, включно з міграцією configured-plugin install.
|
||||
`plugin-deps-cleanup`, `configured-plugin-installs`,
|
||||
`stale-source-plugin-shadow`, `tilde-log-path` і `versioned-runtime-deps`. В aggregate runs
|
||||
`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі
|
||||
сценарії, сформовані як reported issues, включно з configured-plugin install migration.
|
||||
|
||||
Повна update migration навмисно відокремлена від Full Release CI. Використовуйте
|
||||
ручний workflow `Update Migration`, коли питання релізу звучить так: "чи може кожен
|
||||
опублікований stable release від 2026.4.23 і далі оновитися до цього кандидата і
|
||||
очистити plugin dependency debris?":
|
||||
Full update migration навмисно відокремлена від Full Release CI. Використовуйте
|
||||
manual workflow `Update Migration`, коли release question звучить як "чи може
|
||||
кожен опублікований stable release від 2026.4.23 і далі оновитися до цього
|
||||
candidate і очистити plugin dependency debris?":
|
||||
|
||||
```bash
|
||||
gh workflow run update-migration.yml \
|
||||
@ -150,27 +154,27 @@ gh workflow run update-migration.yml \
|
||||
|
||||
## Package Acceptance
|
||||
|
||||
Package Acceptance — це GitHub-native package gate. Він resolve-ить один пакет-кандидат
|
||||
у tarball `package-under-test`, записує версію та SHA-256, а потім
|
||||
Package Acceptance є GitHub-native package gate. Він розвʼязує один candidate
|
||||
package у tarball `package-under-test`, записує version і SHA-256, а потім
|
||||
запускає reusable Docker E2E lanes проти саме цього tarball. Workflow harness
|
||||
ref відокремлений від package source ref, тому поточна логіка тестів може перевіряти
|
||||
старіші trusted releases.
|
||||
ref відокремлений від package source ref, тому поточна test logic може
|
||||
перевіряти старіші trusted releases.
|
||||
|
||||
Джерела кандидатів:
|
||||
Candidate sources:
|
||||
|
||||
- `source=npm`: перевірити `openclaw@beta`, `openclaw@latest` або точну
|
||||
опубліковану версію.
|
||||
- `source=ref`: запакувати trusted branch, tag або commit з вибраним поточним
|
||||
published version.
|
||||
- `source=ref`: запакувати trusted branch, tag або commit з вибраним current
|
||||
harness.
|
||||
- `source=url`: перевірити HTTPS tarball з обов’язковим `package_sha256`.
|
||||
- `source=url`: перевірити HTTPS tarball з обовʼязковим `package_sha256`.
|
||||
- `source=artifact`: повторно використати tarball, завантажений іншим Actions run.
|
||||
|
||||
Full Release Validation за замовчуванням використовує `source=artifact`, побудований із
|
||||
resolved release SHA. Для post-publish доказу передайте
|
||||
Full Release Validation типово використовує `source=artifact`, зібраний із
|
||||
resolved release SHA. Для post-publish proof передайте
|
||||
`package_acceptance_package_spec=openclaw@YYYY.M.D`, щоб та сама upgrade matrix
|
||||
цілилася в shipped npm package натомість.
|
||||
цілилася в shipped npm package.
|
||||
|
||||
Release checks викликають Package Acceptance з package/update/plugin set:
|
||||
Release checks викликають Package Acceptance із package/update/plugin set:
|
||||
|
||||
```text
|
||||
doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update
|
||||
@ -184,17 +188,17 @@ published_upgrade_survivor_scenarios=reported-issues
|
||||
telegram_mode=mock-openai
|
||||
```
|
||||
|
||||
Це тримає package migration, update channel switching, cleanup застарілих plugin dependency,
|
||||
offline-покриття Plugin, поведінку оновлення Plugin і Telegram package
|
||||
QA на тому самому resolved artifact.
|
||||
Це тримає package migration, update channel switching, stale plugin dependency
|
||||
cleanup, offline plugin coverage, plugin update behavior і Telegram package QA
|
||||
на одному resolved artifact.
|
||||
|
||||
`all-since-2026.4.23` — це upgrade sample Full Release CI: кожен stable npm-published release від `2026.4.23` до `latest`. Для вичерпного покриття published
|
||||
update migration використовуйте `all-since-2026.4.23` в окремому workflow Update
|
||||
Migration замість Full Release CI. `release-history` залишається
|
||||
`all-since-2026.4.23` є upgrade sample для Full Release CI: кожен stable npm-published release від `2026.4.23` до `latest`. Для exhaustive coverage
|
||||
published update migration використовуйте `all-since-2026.4.23` в окремому
|
||||
workflow Update Migration замість Full Release CI. `release-history` лишається
|
||||
доступним для ручного ширшого sampling, коли вам також потрібен legacy pre-date
|
||||
anchor.
|
||||
|
||||
Запустіть package profile вручну під час перевірки кандидата перед релізом:
|
||||
Запустіть package profile вручну під час перевірки candidate перед release:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -208,70 +212,73 @@ gh workflow run package-acceptance.yml \
|
||||
-f telegram_mode=mock-openai
|
||||
```
|
||||
|
||||
Використовуйте `suite_profile=product`, коли питання релізу включає MCP-канали,
|
||||
cleanup cron/subagent, OpenAI web search або OpenWebUI. Використовуйте `suite_profile=full`
|
||||
лише тоді, коли потрібне повне Docker-покриття release-path.
|
||||
Використовуйте `suite_profile=product`, коли release question включає MCP
|
||||
channels, cleanup cron/subagent, OpenAI web search або OpenWebUI.
|
||||
Використовуйте `suite_profile=full` лише тоді, коли потрібне повне покриття
|
||||
Docker release-path.
|
||||
|
||||
## Типове значення для релізу
|
||||
## Стандарт для release
|
||||
|
||||
Для release candidates типовий стек доказів такий:
|
||||
Для release candidates стандартний proof stack такий:
|
||||
|
||||
1. `pnpm check:changed` і `pnpm test:changed` для source-level regressions.
|
||||
2. `pnpm release:check` для цілісності артефакту пакета.
|
||||
3. Package Acceptance `package` profile або release-check custom package
|
||||
1. `pnpm check:changed` і `pnpm test:changed` для регресій на рівні source.
|
||||
2. `pnpm release:check` для цілісності package artifact.
|
||||
3. Package Acceptance profile `package` або release-check custom package
|
||||
lanes для контрактів install/update/plugin.
|
||||
4. Cross-OS release checks для OS-specific installer, onboarding і platform
|
||||
behavior.
|
||||
5. Live-набори лише тоді, коли змінена surface торкається поведінки провайдера або hosted-service.
|
||||
5. Live suites лише тоді, коли змінена surface торкається provider або hosted-service
|
||||
behavior.
|
||||
|
||||
На maintainer machines широкі gates і Docker/package product proof мають запускатися
|
||||
в Testbox, якщо явно не виконується local proof.
|
||||
На maintainer machines широкі gates і Docker/package product proof мають
|
||||
запускатися в Testbox, якщо явно не виконується local proof.
|
||||
|
||||
## Legacy-сумісність
|
||||
## Legacy compatibility
|
||||
|
||||
Leniency сумісності є вузькою і time boxed:
|
||||
Compatibility leniency є вузькою і обмеженою в часі:
|
||||
|
||||
- Пакети до `2026.4.25` включно, включно з `2026.4.25-beta.*`, можуть tolerates
|
||||
вже shipped package metadata gaps у Package Acceptance.
|
||||
- Опублікований пакет `2026.4.26` може попереджати про local build metadata stamp
|
||||
files, які вже були shipped.
|
||||
- Пізніші пакети мають відповідати modern contracts. Ті самі gaps fail замість
|
||||
warning або skipping.
|
||||
- Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть
|
||||
толерувати вже shipped package metadata gaps у Package Acceptance.
|
||||
- Опублікований package `2026.4.26` може попереджати про local build metadata
|
||||
stamp files, які вже shipped.
|
||||
- Пізніші packages мають відповідати сучасним контрактам. Ті самі gaps
|
||||
fail замість warning або skipping.
|
||||
|
||||
Не додавайте нові startup migrations для цих старих shapes. Додайте або розширте doctor
|
||||
repair, потім доведіть це за допомогою `upgrade-survivor` або `published-upgrade-survivor`.
|
||||
Не додавайте нові startup migrations для цих старих форм. Додайте або
|
||||
розширте doctor repair, потім підтвердьте це через `upgrade-survivor` або
|
||||
`published-upgrade-survivor`.
|
||||
|
||||
## Додавання покриття
|
||||
|
||||
Коли змінюєте поведінку оновлення або Plugin, додавайте покриття на найнижчому рівні, який
|
||||
може fail з правильної причини:
|
||||
Коли змінюєте update або plugin behavior, додавайте coverage на найнижчому
|
||||
рівні, який може fail з правильної причини:
|
||||
|
||||
- Чиста path або metadata logic: unit test поруч із source.
|
||||
- Package inventory або packed-file behavior: `package-dist-inventory` або tarball
|
||||
checker test.
|
||||
- Pure path або metadata logic: unit test поруч із source.
|
||||
- Package inventory або packed-file behavior: `package-dist-inventory` або
|
||||
tarball checker test.
|
||||
- CLI install/update behavior: Docker lane assertion або fixture.
|
||||
- Published-release migration behavior: сценарій `published-upgrade-survivor`.
|
||||
- Registry/package source behavior: fixture `test:docker:plugins` або сервер fixture
|
||||
ClawHub.
|
||||
- Published-release migration behavior: scenario `published-upgrade-survivor`.
|
||||
- Registry/package source behavior: fixture `test:docker:plugins` або ClawHub
|
||||
fixture server.
|
||||
- Dependency layout або cleanup behavior: перевіряйте і runtime execution, і
|
||||
filesystem boundary. npm dependencies можуть бути hoisted під managed npm
|
||||
root, тому тести мають довести, що root сканується/очищається, замість припускати
|
||||
package-local дерево `node_modules`.
|
||||
root, тому тести мають доводити, що root сканується/очищається, замість
|
||||
припускати package-local дерево `node_modules`.
|
||||
|
||||
Нові Docker fixtures за замовчуванням мають бути hermetic. Використовуйте локальні fixture registries і
|
||||
fake packages, якщо тільки мета тесту не полягає в live registry behavior.
|
||||
Нові Docker fixtures типово мають бути hermetic. Використовуйте local fixture
|
||||
registries і fake packages, якщо метою тесту не є live registry behavior.
|
||||
|
||||
## Тріаж помилок
|
||||
## Тріаж збоїв
|
||||
|
||||
Починайте з ідентичності артефакту:
|
||||
Починайте з artifact identity:
|
||||
|
||||
- Package Acceptance `resolve_package` summary: source, version, SHA-256 і
|
||||
- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і
|
||||
artifact name.
|
||||
- Docker artifacts: `.artifacts/docker-tests/**/summary.json`,
|
||||
`failures.json`, lane logs і rerun commands.
|
||||
- Upgrade survivor summary: `.artifacts/upgrade-survivor/summary.json`,
|
||||
- Summary upgrade survivor: `.artifacts/upgrade-survivor/summary.json`,
|
||||
включно з baseline version, candidate version, scenario, phase timings і
|
||||
recipe steps.
|
||||
|
||||
Віддавайте перевагу повторному запуску точної failed lane з тим самим package artifact над
|
||||
повторним запуском усього release umbrella.
|
||||
Надавайте перевагу rerun точного failed lane з тим самим package artifact, а не
|
||||
rerun усього release umbrella.
|
||||
|
||||
@ -1,24 +1,23 @@
|
||||
---
|
||||
read_when:
|
||||
- Вам потрібні короткі приклади встановлення, виведення списку, оновлення або видалення Plugin
|
||||
- Ви хочете вибрати між ClawHub і розповсюдженням плагінів через npm
|
||||
- Вам потрібні швидкі приклади встановлення, перегляду списку, оновлення або видалення Plugin
|
||||
- Ви хочете вибрати між ClawHub і розповсюдженням Plugin через npm
|
||||
- Ви публікуєте пакет Plugin
|
||||
sidebarTitle: Manage plugins
|
||||
summary: Короткі приклади встановлення, перегляду списку, видалення, оновлення та публікації плагінів OpenClaw
|
||||
title: Керування Plugin
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T21:59:46Z"
|
||||
generated_at: "2026-05-04T20:59:59Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: ec25a811b942f155f5d5e4cac475dbef74f0616bc85ff182c74598184e910320
|
||||
source_hash: 7fa7aa78c1ba9c83ba09bea073987ed5e037031f7c7f29307fe18934b0bd2a1c
|
||||
source_path: plugins/manage-plugins.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
Більшість робочих процесів із plugin складаються з кількох команд: пошук, установлення, перезапуск Gateway,
|
||||
перевірка та видалення, коли plugin більше не потрібен.
|
||||
Більшість робочих процесів із плагінами складаються з кількох команд: пошук, встановлення, перезапуск Gateway, перевірка та видалення, коли плагін більше не потрібен.
|
||||
|
||||
## Список plugins
|
||||
## Список плагінів
|
||||
|
||||
```bash
|
||||
openclaw plugins list
|
||||
@ -27,20 +26,16 @@ openclaw plugins list --verbose
|
||||
openclaw plugins list --json
|
||||
```
|
||||
|
||||
Використовуйте `--json` для скриптів. Він містить діагностику реєстру та статичний
|
||||
`dependencyStatus` кожного plugin, коли пакет plugin оголошує `dependencies` або
|
||||
`optionalDependencies`.
|
||||
Використовуйте `--json` для скриптів. Він містить діагностику реєстру та статичний `dependencyStatus` кожного плагіна, коли пакет плагіна оголошує `dependencies` або `optionalDependencies`.
|
||||
|
||||
```bash
|
||||
openclaw plugins list --json \
|
||||
| jq '.plugins[] | {id, enabled, format, source, dependencyStatus}'
|
||||
```
|
||||
|
||||
`plugins list` — це холодна перевірка інвентаризації. Вона показує, що OpenClaw може виявити
|
||||
з конфігурації, маніфестів і реєстру plugin; вона не доводить, що вже запущений
|
||||
процес Gateway імпортував runtime plugin.
|
||||
`plugins list` — це холодна перевірка інвентарю. Вона показує, що OpenClaw може виявити з конфігурації, маніфестів і реєстру плагінів; вона не доводить, що вже запущений процес Gateway імпортував runtime плагіна.
|
||||
|
||||
## Установлення plugins
|
||||
## Встановлення плагінів
|
||||
|
||||
```bash
|
||||
# Search ClawHub for plugin packages.
|
||||
@ -65,18 +60,16 @@ openclaw plugins install ./my-plugin
|
||||
openclaw plugins install --link ./my-plugin
|
||||
```
|
||||
|
||||
Після встановлення коду plugin перезапустіть Gateway, який обслуговує ваші канали:
|
||||
Після встановлення коду плагіна перезапустіть Gateway, який обслуговує ваші канали:
|
||||
|
||||
```bash
|
||||
openclaw gateway restart
|
||||
openclaw plugins inspect <plugin-id> --runtime --json
|
||||
```
|
||||
|
||||
Використовуйте `inspect --runtime`, коли потрібен доказ, що plugin зареєстрував runtime-
|
||||
поверхні, як-от інструменти, хуки, сервіси, методи Gateway або CLI-
|
||||
команди, що належать plugin.
|
||||
Використовуйте `inspect --runtime`, коли вам потрібен доказ, що плагін зареєстрував runtime-поверхні, як-от інструменти, хуки, сервіси, методи Gateway або CLI-команди, що належать плагіну.
|
||||
|
||||
## Оновлення plugins
|
||||
## Оновлення плагінів
|
||||
|
||||
```bash
|
||||
openclaw plugins update <plugin-id>
|
||||
@ -84,24 +77,18 @@ openclaw plugins update <npm-package-or-spec>
|
||||
openclaw plugins update --all
|
||||
```
|
||||
|
||||
Якщо plugin було встановлено з npm dist-tag, наприклад `@beta`, подальші виклики
|
||||
`update <plugin-id>` повторно використовують цей записаний тег. Передавання явної npm-специфікації
|
||||
перемикає відстежуване встановлення на цю специфікацію для майбутніх оновлень.
|
||||
Якщо плагін було встановлено з npm dist-tag, наприклад `@beta`, подальші виклики `update <plugin-id>` повторно використовують цей записаний тег. Передавання явної npm-специфікації перемикає відстежуване встановлення на цю специфікацію для майбутніх оновлень.
|
||||
|
||||
```bash
|
||||
openclaw plugins update @scope/openclaw-plugin@beta
|
||||
openclaw plugins update @scope/openclaw-plugin
|
||||
```
|
||||
|
||||
Друга команда повертає plugin до типової лінії випусків реєстру,
|
||||
якщо раніше він був закріплений за точною версією або тегом.
|
||||
Друга команда повертає плагін до стандартної лінії випусків реєстру, якщо раніше він був закріплений за точною версією або тегом.
|
||||
|
||||
Коли `openclaw update` запускається на beta-каналі, записи plugin npm і ClawHub
|
||||
типової лінії спершу пробують відповідний випуск plugin `@beta`. Якщо такого beta-
|
||||
випуску не існує, OpenClaw повертається до записаної типової/latest специфікації.
|
||||
Точні версії та явні теги, як-от `@rc` або `@beta`, зберігаються.
|
||||
Коли `openclaw update` виконується на beta-каналі, записи npm і ClawHub-плагінів зі стандартної лінії спочатку пробують відповідний випуск плагіна `@beta`. Якщо такого beta-випуску не існує, OpenClaw повертається до записаної стандартної/найновішої специфікації. Для npm-плагінів OpenClaw також повертається до неї, коли beta-пакет існує, але не проходить перевірку встановлення. Точні версії та явні теги, як-от `@rc` або `@beta`, зберігаються.
|
||||
|
||||
## Видалення plugins
|
||||
## Видалення плагінів
|
||||
|
||||
```bash
|
||||
openclaw plugins uninstall <plugin-id> --dry-run
|
||||
@ -110,20 +97,15 @@ openclaw plugins uninstall <plugin-id> --keep-files
|
||||
openclaw gateway restart
|
||||
```
|
||||
|
||||
Видалення прибирає запис конфігурації plugin, запис індексу plugin, записи списків allow/deny
|
||||
і пов’язані шляхи завантаження, коли це застосовно. Керовані каталоги встановлення
|
||||
видаляються, якщо ви не передали `--keep-files`.
|
||||
Видалення прибирає конфігураційний запис плагіна, запис індексу плагінів, записи списків дозволів/заборон і пов’язані шляхи завантаження, коли це застосовно. Керовані каталоги встановлення видаляються, якщо ви не передасте `--keep-files`.
|
||||
|
||||
## Публікація plugins
|
||||
## Публікація плагінів
|
||||
|
||||
Ви можете публікувати зовнішні plugins у [ClawHub](https://clawhub.ai), npmjs.com або
|
||||
в обох місцях.
|
||||
Ви можете публікувати зовнішні плагіни в [ClawHub](https://clawhub.ai), npmjs.com або в обидва місця.
|
||||
|
||||
### Публікація в ClawHub
|
||||
|
||||
ClawHub — це основна публічна поверхня виявлення для plugins OpenClaw. Він надає
|
||||
користувачам метадані з пошуком, історію версій і результати сканування реєстру перед
|
||||
установленням.
|
||||
ClawHub — це основна публічна поверхня виявлення плагінів OpenClaw. Вона надає користувачам доступні для пошуку метадані, історію версій і результати сканування реєстру перед встановленням.
|
||||
|
||||
```bash
|
||||
npm i -g clawhub
|
||||
@ -133,19 +115,18 @@ clawhub package publish your-org/your-plugin
|
||||
clawhub package publish your-org/your-plugin@v1.0.0
|
||||
```
|
||||
|
||||
Користувачі встановлюють із ClawHub так:
|
||||
Користувачі встановлюють із ClawHub за допомогою:
|
||||
|
||||
```bash
|
||||
openclaw plugins install clawhub:<package>
|
||||
openclaw plugins install <package>
|
||||
```
|
||||
|
||||
Форма без префікса все одно спочатку перевіряє ClawHub.
|
||||
Скорочена форма й надалі спочатку перевіряє ClawHub.
|
||||
|
||||
### Публікація в npmjs.com
|
||||
|
||||
Нативні npm plugins мають містити маніфест plugin і метадані точки входу OpenClaw
|
||||
у `package.json`.
|
||||
Нативні npm-плагіни мають містити маніфест плагіна та метадані точки входу OpenClaw у `package.json`.
|
||||
|
||||
```json package.json
|
||||
{
|
||||
@ -162,7 +143,7 @@ openclaw plugins install <package>
|
||||
npm publish --access public
|
||||
```
|
||||
|
||||
Користувачі встановлюють npm-only так:
|
||||
Користувачі встановлюють лише з npm за допомогою:
|
||||
|
||||
```bash
|
||||
openclaw plugins install npm:@acme/openclaw-plugin
|
||||
@ -170,23 +151,19 @@ openclaw plugins install npm:@acme/openclaw-plugin@beta
|
||||
openclaw plugins install npm:@acme/openclaw-plugin@1.0.0
|
||||
```
|
||||
|
||||
Якщо той самий пакет також доступний у ClawHub, `npm:` пропускає пошук у ClawHub і
|
||||
примусово використовує розв’язання через npm.
|
||||
Якщо той самий пакет також доступний у ClawHub, `npm:` пропускає пошук у ClawHub і примусово використовує розв’язання через npm.
|
||||
|
||||
## Вибір джерела
|
||||
|
||||
- **ClawHub**: використовуйте, коли потрібні нативне для OpenClaw виявлення, підсумки сканування,
|
||||
версії та підказки щодо встановлення.
|
||||
- **npmjs.com**: використовуйте, коли ви вже постачаєте пакети JavaScript або потребуєте npm
|
||||
dist-tags/робочих процесів приватного реєстру.
|
||||
- **Git**: використовуйте, коли хочете встановлювати безпосередньо з гілки, тега або коміту.
|
||||
- **Локальний шлях**: використовуйте, коли розробляєте або тестуєте plugin на тій самій
|
||||
машині.
|
||||
- **ClawHub**: використовуйте, коли потрібні нативне для OpenClaw виявлення, підсумки сканування, версії та підказки зі встановлення.
|
||||
- **npmjs.com**: використовуйте, коли ви вже постачаєте JavaScript-пакети або потребуєте робочих процесів npm dist-tag/приватного реєстру.
|
||||
- **Git**: використовуйте, коли хочете встановити безпосередньо з гілки, тегу або коміту.
|
||||
- **Локальний шлях**: використовуйте, коли розробляєте або тестуєте плагін на тому самому комп’ютері.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Plugins](/uk/tools/plugin) - огляд і усунення несправностей
|
||||
- [Плагіни](/uk/tools/plugin) - огляд і усунення несправностей
|
||||
- [`openclaw plugins`](/uk/cli/plugins) - повна довідка CLI
|
||||
- [ClawHub](/uk/tools/clawhub) - публікація та операції реєстру
|
||||
- [Створення plugins](/uk/plugins/building-plugins) - створення пакета plugin
|
||||
- [Маніфест plugin](/uk/plugins/manifest) - маніфест і метадані пакета
|
||||
- [ClawHub](/uk/tools/clawhub) - публікація та операції з реєстром
|
||||
- [Створення плагінів](/uk/plugins/building-plugins) - створення пакета плагіна
|
||||
- [Маніфест плагіна](/uk/plugins/manifest) - маніфест і метадані пакета
|
||||
|
||||
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue
Block a user