chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
c64d7119e6
commit
9871fcf516
@ -1,26 +1,26 @@
|
||||
---
|
||||
read_when:
|
||||
- Підготовка звіту про помилку або запиту на підтримку
|
||||
- Налагодження аварійних завершень Gateway, перезапусків, тиску на пам’ять або надмірно великих корисних навантажень
|
||||
- Налагодження аварійних завершень Gateway, перезапусків, тиску на пам’ять або завеликих корисних навантажень
|
||||
- Перегляд того, які діагностичні дані записуються або приховуються
|
||||
summary: Створюйте поширювані діагностичні пакети Gateway для звітів про помилки
|
||||
summary: Створюйте діагностичні пакети Gateway для звітів про помилки, якими можна ділитися
|
||||
title: Експорт діагностики
|
||||
x-i18n:
|
||||
generated_at: "2026-05-02T04:01:30Z"
|
||||
generated_at: "2026-05-03T18:32:10Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 4d1f7c1e1d96aeeebe30b30c8a23ec3c7b0fb4938f15a3783bf22e861770bf78
|
||||
source_hash: f6cf8e00fe8033e339b5c947ce3dd10fdee736048a358ad3a0c2ccb77e939f4b
|
||||
source_path: gateway/diagnostics.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw може створити локальний zip-файл діагностики для звітів про помилки. Він об’єднує
|
||||
очищені стан Gateway, працездатність, журнали, форму конфігурації та нещодавні
|
||||
події стабільності без вмісту payload.
|
||||
OpenClaw може створити локальний zip-архів діагностики для звітів про помилки. Він поєднує
|
||||
санітизований стан Gateway, справність, журнали, форму конфігурації та нещодавні події
|
||||
стабільності без payload.
|
||||
|
||||
Ставтеся до діагностичних пакетів як до секретів, доки не переглянете їх. Вони
|
||||
спроєктовані так, щоб пропускати або редагувати payload і облікові дані, але все одно підсумовують
|
||||
локальні журнали Gateway і стан runtime на рівні хоста.
|
||||
спроєктовані так, щоб пропускати або редагувати payload і облікові дані, але все одно узагальнюють
|
||||
локальні журнали Gateway і стан середовища виконання на рівні хоста.
|
||||
|
||||
## Швидкий старт
|
||||
|
||||
@ -28,7 +28,7 @@ OpenClaw може створити локальний zip-файл діагно
|
||||
openclaw gateway diagnostics export
|
||||
```
|
||||
|
||||
Команда друкує шлях до записаного zip-файлу. Щоб вибрати шлях:
|
||||
Команда виводить шлях до записаного zip-архіву. Щоб вибрати шлях:
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export --output openclaw-diagnostics.zip
|
||||
@ -43,91 +43,92 @@ openclaw gateway diagnostics export --json
|
||||
## Команда чату
|
||||
|
||||
Власники можуть використовувати `/diagnostics [note]` у чаті, щоб запросити локальний експорт Gateway.
|
||||
Використовуйте це, коли помилка сталася в реальній розмові і вам потрібен один
|
||||
звіт для підтримки, який можна скопіювати й вставити:
|
||||
Використовуйте це, коли помилка сталася в реальній розмові й потрібен один
|
||||
звіт для підтримки, який можна скопіювати та вставити:
|
||||
|
||||
1. Надішліть `/diagnostics` у розмові, де ви помітили проблему. Додайте
|
||||
коротку нотатку, якщо це допоможе, наприклад `/diagnostics bad tool choice`.
|
||||
2. OpenClaw надсилає вступ до діагностики та просить одне явне схвалення exec.
|
||||
Схвалення запускає `openclaw gateway diagnostics export --json`.
|
||||
Не схвалюйте діагностику через правило allow-all.
|
||||
3. Після схвалення OpenClaw відповідає звітом для вставлення, що містить локальний
|
||||
шлях пакета, підсумок маніфесту, примітки щодо приватності та відповідні ідентифікатори сесій.
|
||||
2. OpenClaw надсилає преамбулу діагностики й просить одне явне підтвердження exec.
|
||||
Підтвердження запускає `openclaw gateway diagnostics export --json`.
|
||||
Не підтверджуйте діагностику через правило allow-all.
|
||||
3. Після підтвердження OpenClaw відповідає звітом для вставлення, який містить локальний
|
||||
шлях до пакета, підсумок маніфесту, нотатки про приватність і відповідні ідентифікатори сеансів.
|
||||
|
||||
У групових чатах власник усе ще може запустити `/diagnostics`, але OpenClaw не
|
||||
публікує діагностичні подробиці назад у спільний чат. Він надсилає вступ,
|
||||
запити схвалення, результат експорту Gateway і розбір сесії/треду Codex
|
||||
власнику через приватний маршрут схвалення. Група отримує лише коротке повідомлення
|
||||
про те, що діагностичний потік було надіслано приватно. Якщо OpenClaw не може знайти приватний
|
||||
У групових чатах власник усе ще може запускати `/diagnostics`, але OpenClaw не
|
||||
публікує діагностичні деталі назад у спільний чат. Він надсилає преамбулу,
|
||||
запити підтвердження, результат експорту Gateway і розбивку сеансів/потоків Codex
|
||||
власнику через приватний маршрут підтвердження. Група отримує лише коротке сповіщення
|
||||
про те, що діагностичний процес було надіслано приватно. Якщо OpenClaw не може знайти приватний
|
||||
маршрут до власника, команда завершується безпечною відмовою і просить власника запустити її з DM.
|
||||
|
||||
Коли активна сесія OpenClaw використовує нативний harness OpenAI Codex,
|
||||
те саме схвалення exec також покриває завантаження відгуку OpenAI для тредів runtime
|
||||
Codex, про які знає OpenClaw. Це завантаження окреме від локального zip-файлу
|
||||
Gateway і з’являється лише для сесій harness Codex. Перед схваленням
|
||||
запит пояснює, що схвалення діагностики також надішле відгук Codex, але він
|
||||
не перелічує ідентифікатори сесій або тредів Codex. Після схвалення відповідь у чаті перелічує
|
||||
канали, ідентифікатори сесій OpenClaw, ідентифікатори тредів Codex і локальні команди resume
|
||||
для тредів, надісланих на сервери OpenAI. Якщо ви відхилите або проігноруєте
|
||||
схвалення, OpenClaw не запускає експорт, не надсилає відгук Codex і
|
||||
не друкує ідентифікатори Codex.
|
||||
Коли активний сеанс OpenClaw використовує нативний OpenAI Codex harness,
|
||||
те саме підтвердження exec також охоплює завантаження відгуку OpenAI для потоків
|
||||
середовища виконання Codex, про які знає OpenClaw. Це завантаження є окремим від локального
|
||||
zip-архіву Gateway і з'являється лише для сеансів Codex harness. Перед підтвердженням
|
||||
запит пояснює, що підтвердження діагностики також надішле відгук Codex, але він
|
||||
не перелічує ідентифікатори сеансів або потоків Codex. Після підтвердження відповідь у чаті перелічує
|
||||
канали, ідентифікатори сеансів OpenClaw, ідентифікатори потоків Codex і локальні команди відновлення
|
||||
для потоків, надісланих на сервери OpenAI. Якщо ви відхилите або проігноруєте
|
||||
підтвердження, OpenClaw не запускає експорт, не надсилає відгук Codex і
|
||||
не виводить ідентифікатори Codex.
|
||||
|
||||
Це робить звичний цикл налагодження Codex коротким: помітили погану поведінку в
|
||||
Telegram, Discord або іншому каналі, запустили `/diagnostics`, один раз схвалили, поділилися
|
||||
звітом із підтримкою, а потім локально запустили надруковану команду `codex resume <thread-id>`,
|
||||
якщо хочете самостійно перевірити нативний тред Codex. Див.
|
||||
[Harness Codex](/uk/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) для
|
||||
цього робочого процесу перевірки.
|
||||
Це робить типовий цикл налагодження Codex коротким: помітили неправильну поведінку в
|
||||
Telegram, Discord або іншому каналі, запустили `/diagnostics`, один раз підтвердили, поділилися
|
||||
звітом із підтримкою, а потім локально запустили виведену команду `codex resume <thread-id>`,
|
||||
якщо хочете самостійно перевірити нативний потік Codex. Див.
|
||||
[Codex harness](/uk/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) для
|
||||
цього процесу перевірки.
|
||||
|
||||
## Що містить експорт
|
||||
|
||||
Zip-файл містить:
|
||||
Zip-архів містить:
|
||||
|
||||
- `summary.md`: зручний для людини огляд для підтримки.
|
||||
- `diagnostics.json`: машиночитний підсумок конфігурації, журналів, стану, працездатності
|
||||
- `summary.md`: зручний для читання огляд для підтримки.
|
||||
- `diagnostics.json`: машинозчитуваний підсумок конфігурації, журналів, стану, справності
|
||||
та даних стабільності.
|
||||
- `manifest.json`: метадані експорту та список файлів.
|
||||
- Очищену форму конфігурації та несекретні подробиці конфігурації.
|
||||
- Очищені підсумки журналів і нещодавні відредаговані рядки журналів.
|
||||
- Best-effort знімки стану та працездатності Gateway.
|
||||
- `stability/latest.json`: найновіший збережений пакет стабільності, коли він доступний.
|
||||
- `manifest.json`: метадані експорту й список файлів.
|
||||
- Санітизовану форму конфігурації та несекретні деталі конфігурації.
|
||||
- Санітизовані підсумки журналів і нещодавні відредаговані рядки журналів.
|
||||
- Найкращі можливі знімки стану й справності Gateway.
|
||||
- `stability/latest.json`: найновіший збережений пакет стабільності, коли доступний.
|
||||
|
||||
Експорт корисний навіть тоді, коли Gateway непрацездатний. Якщо Gateway не може
|
||||
відповісти на запити стану або працездатності, локальні журнали, форма конфігурації та найновіший
|
||||
пакет стабільності все одно збираються, коли вони доступні.
|
||||
Експорт корисний навіть тоді, коли Gateway несправний. Якщо Gateway не може
|
||||
відповісти на запити стану або справності, локальні журнали, форма конфігурації та найновіший
|
||||
пакет стабільності все одно збираються, коли доступні.
|
||||
|
||||
## Модель приватності
|
||||
|
||||
Діагностику спроєктовано так, щоб нею можна було ділитися. Експорт зберігає операційні дані,
|
||||
Діагностика спроєктована так, щоб нею можна було ділитися. Експорт зберігає операційні дані,
|
||||
які допомагають налагодженню, як-от:
|
||||
|
||||
- назви підсистем, ідентифікатори plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими
|
||||
- коди стану, тривалості, кількість байтів, стан черги та показники пам’яті
|
||||
- очищені метадані журналів і відредаговані операційні повідомлення
|
||||
- назви підсистем, ідентифікатори Plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими
|
||||
- коди стану, тривалості, кількість байтів, стан черги та показники пам'яті
|
||||
- санітизовані метадані журналів і відредаговані операційні повідомлення
|
||||
- форму конфігурації та несекретні налаштування функцій
|
||||
|
||||
Експорт пропускає або редагує:
|
||||
|
||||
- текст чату, промпти, інструкції, тіла webhook і результати інструментів
|
||||
- текст чатів, промпти, інструкції, тіла webhook і результати інструментів
|
||||
- облікові дані, API-ключі, токени, cookies і секретні значення
|
||||
- сирі тіла запитів або відповідей
|
||||
- ідентифікатори облікових записів, ідентифікатори повідомлень, сирі ідентифікатори сесій, імена хостів і локальні імена користувачів
|
||||
- необроблені тіла запитів або відповідей
|
||||
- ідентифікатори облікових записів, ідентифікатори повідомлень, необроблені ідентифікатори сеансів, імена хостів і локальні імена користувачів
|
||||
|
||||
Коли повідомлення журналу схоже на текст користувача, чату, промпта або payload інструмента,
|
||||
експорт зберігає лише те, що повідомлення було пропущено, і кількість байтів.
|
||||
Коли повідомлення журналу схоже на текст payload користувача, чату, промпта або інструмента,
|
||||
експорт зберігає лише факт пропуску повідомлення та кількість байтів.
|
||||
|
||||
## Реєстратор стабільності
|
||||
|
||||
Gateway типово записує обмежений потік стабільності без payload, коли
|
||||
Gateway за замовчуванням записує обмежений потік стабільності без payload, коли
|
||||
діагностику ввімкнено. Він призначений для операційних фактів, а не для вмісту.
|
||||
|
||||
Той самий діагностичний heartbeat записує зразки життєздатності, коли Gateway продовжує
|
||||
працювати, але event loop Node.js або CPU виглядає перевантаженим. Ці
|
||||
події `diagnostic.liveness.warning` містять затримку event loop, використання event loop,
|
||||
співвідношення CPU-core і кількість активних/очікуваних/поставлених у чергу сесій. Неактивні
|
||||
зразки залишаються в телеметрії на рівні `info`; вони логуються як попередження Gateway
|
||||
лише коли діагностична робота активна, очікує або стоїть у черзі. Вони самі по собі
|
||||
не перезапускають Gateway.
|
||||
Той самий діагностичний heartbeat записує зразки активності, коли Gateway продовжує
|
||||
працювати, але event loop Node.js або CPU здаються перевантаженими. Ці події
|
||||
`diagnostic.liveness.warning` містять затримку event loop, використання event loop,
|
||||
співвідношення ядер CPU та кількість активних/очікувальних/поставлених у чергу сеансів. Неактивні
|
||||
зразки залишаються в телеметрії на рівні `info`. Зразки активності стають попередженнями Gateway
|
||||
лише тоді, коли робота очікує або стоїть у черзі, або коли активна робота збігається зі
|
||||
сталою затримкою event loop. Тимчасові піки максимальної затримки під час загалом справної
|
||||
фонової роботи залишаються в журналах debug. Вони самі по собі не перезапускають Gateway.
|
||||
|
||||
Перевірити активний реєстратор:
|
||||
|
||||
@ -137,22 +138,22 @@ openclaw gateway stability --type payload.large
|
||||
openclaw gateway stability --json
|
||||
```
|
||||
|
||||
Перевірити найновіший збережений пакет стабільності після фатального виходу, тайм-ауту завершення роботи
|
||||
або помилки запуску після перезапуску:
|
||||
Перевірити найновіший збережений пакет стабільності після фатального завершення, тайм-ауту
|
||||
завершення роботи або помилки запуску після перезапуску:
|
||||
|
||||
```bash
|
||||
openclaw gateway stability --bundle latest
|
||||
```
|
||||
|
||||
Створити zip-файл діагностики з найновішого збереженого пакета:
|
||||
Створити zip-архів діагностики з найновішого збереженого пакета:
|
||||
|
||||
```bash
|
||||
openclaw gateway stability --bundle latest --export
|
||||
```
|
||||
|
||||
Збережені пакети розташовані в `~/.openclaw/logs/stability/`, коли події існують.
|
||||
Збережені пакети розміщуються в `~/.openclaw/logs/stability/`, коли події існують.
|
||||
|
||||
## Корисні параметри
|
||||
## Корисні опції
|
||||
|
||||
```bash
|
||||
openclaw gateway diagnostics export \
|
||||
@ -161,20 +162,20 @@ openclaw gateway diagnostics export \
|
||||
--log-bytes 1000000
|
||||
```
|
||||
|
||||
- `--output <path>`: записати до конкретного шляху zip-файлу.
|
||||
- `--log-lines <count>`: максимальна кількість очищених рядків журналу для включення.
|
||||
- `--output <path>`: записати в конкретний шлях zip-архіву.
|
||||
- `--log-lines <count>`: максимальна кількість санітизованих рядків журналу для включення.
|
||||
- `--log-bytes <bytes>`: максимальна кількість байтів журналу для перевірки.
|
||||
- `--url <url>`: URL WebSocket Gateway для знімків стану та працездатності.
|
||||
- `--token <token>`: токен Gateway для знімків стану та працездатності.
|
||||
- `--password <password>`: пароль Gateway для знімків стану та працездатності.
|
||||
- `--timeout <ms>`: тайм-аут знімків стану та працездатності.
|
||||
- `--url <url>`: WebSocket URL Gateway для знімків стану й справності.
|
||||
- `--token <token>`: токен Gateway для знімків стану й справності.
|
||||
- `--password <password>`: пароль Gateway для знімків стану й справності.
|
||||
- `--timeout <ms>`: тайм-аут знімків стану й справності.
|
||||
- `--no-stability-bundle`: пропустити пошук збереженого пакета стабільності.
|
||||
- `--json`: надрукувати машиночитні метадані експорту.
|
||||
- `--json`: вивести машинозчитувані метадані експорту.
|
||||
|
||||
## Вимкнення діагностики
|
||||
## Вимкнути діагностику
|
||||
|
||||
Діагностику ввімкнено типово. Щоб вимкнути реєстратор стабільності та
|
||||
збирання діагностичних подій:
|
||||
Діагностику ввімкнено за замовчуванням. Щоб вимкнути реєстратор стабільності та
|
||||
збір діагностичних подій:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -184,13 +185,13 @@ openclaw gateway diagnostics export \
|
||||
}
|
||||
```
|
||||
|
||||
Вимкнення діагностики зменшує деталізацію звіту про помилку. Воно не впливає на звичайне
|
||||
логування Gateway.
|
||||
Вимкнення діагностики зменшує деталізацію звіту про помилку. Це не впливає на звичайне
|
||||
журналювання Gateway.
|
||||
|
||||
## Пов’язане
|
||||
## Пов'язане
|
||||
|
||||
- [Перевірки працездатності](/uk/gateway/health)
|
||||
- [Перевірки справності](/uk/gateway/health)
|
||||
- [CLI Gateway](/uk/cli/gateway#gateway-diagnostics-export)
|
||||
- [Протокол Gateway](/uk/gateway/protocol#system-and-identity)
|
||||
- [Логування](/uk/logging)
|
||||
- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — окремий потік для передавання діагностики до колектора
|
||||
- [Журналювання](/uk/logging)
|
||||
- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — окремий процес для потокової передачі діагностики до колектора
|
||||
|
||||
@ -1,284 +1,284 @@
|
||||
---
|
||||
read_when:
|
||||
- Пошук визначень публічних каналів випуску
|
||||
- Запуск перевірки релізу або приймального тестування пакета
|
||||
- Шукаєте іменування версій і періодичність випусків
|
||||
summary: Релізні лінії, контрольний список оператора, валідаційні бокси, іменування версій і періодичність
|
||||
- Запуск валідації релізу або приймання пакета
|
||||
- Пошук відомостей про найменування версій і періодичність випусків
|
||||
summary: Релізні доріжки, контрольний список оператора, середовища валідації, іменування версій і ритм
|
||||
title: Політика випусків
|
||||
x-i18n:
|
||||
generated_at: "2026-05-03T11:28:46Z"
|
||||
generated_at: "2026-05-03T18:32:10Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: edfd7d6a17da68c76d7196856702c59d1e3c2749907f591fe18b4f9df2eb097d
|
||||
source_hash: 566088d826e1e2bac21b11443b82b62cb73ed1fd9c508c3fb865149cf8a428ba
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
OpenClaw має три публічні канали випусків:
|
||||
|
||||
- stable: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest` за явним запитом
|
||||
- beta: передвипускні теги, які публікуються в npm `beta`
|
||||
- stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
|
||||
- beta: теги попередніх випусків, які публікуються в npm `beta`
|
||||
- dev: рухома вершина `main`
|
||||
|
||||
## Іменування версій
|
||||
## Назви версій
|
||||
|
||||
- Версія стабільного випуску: `YYYY.M.D`
|
||||
- Git-тег: `vYYYY.M.D`
|
||||
- Версія стабільного коригувального випуску: `YYYY.M.D-N`
|
||||
- Git-тег: `vYYYY.M.D-N`
|
||||
- Версія beta-передвипуску: `YYYY.M.D-beta.N`
|
||||
- Версія beta-попереднього випуску: `YYYY.M.D-beta.N`
|
||||
- Git-тег: `vYYYY.M.D-beta.N`
|
||||
- Не додавайте початкові нулі до місяця чи дня
|
||||
- Не додавайте нулі на початку місяця або дня
|
||||
- `latest` означає поточний просунутий стабільний випуск npm
|
||||
- `beta` означає поточну ціль встановлення beta
|
||||
- Стабільні та стабільні коригувальні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену beta-збірку
|
||||
- Кожен стабільний випуск OpenClaw постачається разом із пакетом npm і застосунком macOS;
|
||||
beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
|
||||
збирання/підписування/нотаризацію застосунку mac залишають для стабільних випусків, якщо це явно не запитано
|
||||
- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або просунути перевірену збірку beta пізніше
|
||||
- Кожен стабільний випуск OpenClaw постачає пакет npm і застосунок macOS разом;
|
||||
beta-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а
|
||||
збирання/підписування/нотаризацію застосунку mac залишають для stable, якщо це явно не запитано
|
||||
|
||||
## Ритм випусків
|
||||
## Періодичність випусків
|
||||
|
||||
- Випуски рухаються спочатку через beta
|
||||
- Випуски рухаються спершу через beta
|
||||
- Stable виходить лише після перевірки останньої beta
|
||||
- Maintainers зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
|
||||
з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
|
||||
- Maintainers зазвичай готують випуски з гілки `release/YYYY.M.D`, створеної
|
||||
з поточної `main`, щоб перевірка випуску та виправлення не блокували нову
|
||||
розробку в `main`
|
||||
- Якщо beta-тег уже надіслано або опубліковано і він потребує виправлення, maintainers створюють
|
||||
наступний тег `-beta.N` замість видалення чи повторного створення старого beta-тега
|
||||
- Докладна процедура випуску, погодження, облікові дані та нотатки щодо відновлення
|
||||
- Якщо тег beta було надіслано або опубліковано і він потребує виправлення, maintainers створюють
|
||||
наступний тег `-beta.N` замість видалення або повторного створення старого тегу beta
|
||||
- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення
|
||||
доступні лише maintainers
|
||||
|
||||
## Контрольний список оператора випуску
|
||||
|
||||
Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в
|
||||
runbook випуску, доступному лише maintainers.
|
||||
Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і подробиці екстреного відкату залишаються в
|
||||
runbook випуску лише для maintainers.
|
||||
|
||||
1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано,
|
||||
і підтвердьте, що поточний CI `main` достатньо зелений, щоб відгалужуватися від нього.
|
||||
2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
|
||||
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте їх, надішліть і виконайте rebase/pull
|
||||
1. Почніть з поточної `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано,
|
||||
і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити з нього гілку.
|
||||
2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою
|
||||
`/changelog`, залиште записи орієнтованими на користувача, закомітьте їх, надішліть і виконайте rebase/pull
|
||||
ще раз перед створенням гілки.
|
||||
3. Перегляньте записи сумісності випуску в
|
||||
`src/plugins/compat/registry.ts` і
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
|
||||
сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її
|
||||
сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її
|
||||
навмисно збережено.
|
||||
4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском
|
||||
4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну роботу над випуском
|
||||
безпосередньо в `main`.
|
||||
5. Підвищте версію в кожному потрібному місці для запланованого тега, запустіть
|
||||
`pnpm plugins:sync`, щоб пакети Plugin, придатні до публікації, мали спільну версію випуску
|
||||
5. Оновіть кожне обов’язкове місце з версією для запланованого тегу, запустіть
|
||||
`pnpm plugins:sync`, щоб придатні до публікації пакети Plugin мали спільну версію випуску
|
||||
та метадані сумісності, потім запустіть локальний детермінований preflight:
|
||||
`pnpm check:test-types`, `pnpm check:architecture`,
|
||||
`pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і
|
||||
`pnpm release:check`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега
|
||||
повний 40-символьний SHA гілки випуску дозволений для preflight лише для перевірки.
|
||||
Збережіть успішний `preflight_run_id`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тегу
|
||||
повний 40-символьний SHA гілки випуску дозволений для validation-only
|
||||
preflight. Збережіть успішний `preflight_run_id`.
|
||||
7. Запустіть усі передрелізні тести через `Full Release Validation` для
|
||||
гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо перевірка не пройшла, виправте в гілці випуску та повторно запустіть найменший файл,
|
||||
канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що
|
||||
гілки випуску, тегу або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо перевірка не проходить, виправте в гілці випуску й повторно запустіть найменший невдалий
|
||||
файл, канал, завдання workflow, профіль пакета, provider або allowlist моделей, який
|
||||
доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить
|
||||
попередні докази застарілими.
|
||||
9. Для beta позначте тегом `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
|
||||
9. Для beta позначте `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
|
||||
відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
|
||||
спочатку публікує всі придатні до публікації пакети Plugin у npm, потім публікує той самий
|
||||
набір у ClawHub, а після цього просуває підготовлений preflight-артефакт npm OpenClaw
|
||||
з відповідним dist-tag. Після публікації запустіть package
|
||||
acceptance після публікації для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
|
||||
`openclaw@beta`. Якщо надісланий або опублікований передвипуск потребує виправлення,
|
||||
створіть наступний відповідний номер передвипуску; не видаляйте й не переписуйте старий
|
||||
передвипуск.
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має
|
||||
потрібні докази перевірки. Публікація stable в npm також проходить через
|
||||
`OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через
|
||||
`preflight_run_id`; готовність стабільного випуску macOS також потребує
|
||||
запакованих `.zip`, `.dmg`, `.dSYM.zip` та оновленого `appcast.xml` у `main`.
|
||||
11. Після публікації запустіть verifier npm після публікації, необов’язковий автономний
|
||||
E2E Telegram для опублікованого npm, коли потрібен доказ каналу після публікації,
|
||||
спершу публікує всі придатні до публікації пакети Plugin в npm, потім публікує той самий
|
||||
набір у ClawHub як tarball-и ClawPack npm-pack, а далі просуває
|
||||
підготовлений артефакт preflight npm OpenClaw з відповідним dist-tag. Після
|
||||
публікації запустіть post-publish package
|
||||
acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
|
||||
`openclaw@beta`. Якщо надісланий або опублікований попередній випуск потребує виправлення,
|
||||
створіть наступний відповідний номер попереднього випуску; не видаляйте і не переписуйте старий
|
||||
попередній випуск.
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або release candidate матиме
|
||||
потрібні докази перевірки. Публікація stable npm також проходить через
|
||||
`OpenClaw Release Publish`, повторно використовуючи успішний артефакт preflight через
|
||||
`preflight_run_id`; готовність stable macOS-випуску також потребує
|
||||
упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
|
||||
11. Після публікації запустіть npm post-publish verifier, необов’язковий standalone
|
||||
published-npm Telegram E2E, коли потрібен доказ каналу після публікації,
|
||||
просування dist-tag за потреби, нотатки GitHub release/prerelease з
|
||||
повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
|
||||
|
||||
## Preflight випуску
|
||||
|
||||
- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
|
||||
покритим поза швидшим локальним gate `pnpm check`
|
||||
покритим поза швидшим локальним шлюзом `pnpm check`
|
||||
- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
|
||||
імпорту та меж архітектури були зеленими поза швидшим локальним gate
|
||||
імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
|
||||
- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
|
||||
релізні артефакти `dist/*` і bundle Control UI існували для етапу
|
||||
перевірки пакування
|
||||
- Запустіть `pnpm plugins:sync` після підняття версії в корені та перед тегуванням. Він
|
||||
оновлює версії публіковних пакетів plugin, метадані сумісності peer/API
|
||||
OpenClaw, метадані збірки та заготовки changelog plugin, щоб вони відповідали версії
|
||||
релізу core. `pnpm plugins:sync:check` — це немутуючий релізний запобіжник;
|
||||
workflow публікації завершується помилкою до будь-якої мутації registry, якщо цей крок було
|
||||
релізні артефакти `dist/*` і бандл Control UI існували для кроку
|
||||
валідації пакування
|
||||
- Запустіть `pnpm plugins:sync` після підняття версії в корені та перед створенням тега. Він
|
||||
оновлює версії пакетів публіковних plugins, метадані сумісності OpenClaw peer/API,
|
||||
метадані збірки та заготовки журналів змін plugins, щоб вони відповідали версії
|
||||
основного релізу. `pnpm plugins:sync:check` — це немутувальний релізний запобіжник;
|
||||
workflow публікації завершується з помилкою до будь-якої мутації реєстру, якщо цей крок було
|
||||
забуто.
|
||||
- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
|
||||
запустити всі передрелізні test boxes з однієї точки входу. Він приймає branch,
|
||||
tag або повний SHA commit, dispatch ручний `CI` і dispatch
|
||||
запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, запускає ручний `CI` і запускає
|
||||
`OpenClaw Release Checks` для install smoke, package acceptance, Docker
|
||||
release-path suite, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
|
||||
lanes. З `release_profile=full` і `rerun_group=all` він також запускає package
|
||||
Telegram E2E проти артефакту `release-package-under-test` із release
|
||||
Telegram E2E проти артефакта `release-package-under-test` із release
|
||||
checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий
|
||||
Telegram E2E має також підтвердити опублікований npm package. Надайте
|
||||
Telegram E2E також має підтвердити опублікований npm-пакет. Надайте
|
||||
`package_acceptance_package_spec` після публікації, коли Package Acceptance
|
||||
має запускати свою матрицю package/update проти відвантаженого npm package замість
|
||||
артефакту, зібраного за SHA. Надайте
|
||||
`evidence_package_spec`, коли приватний evidence report має підтвердити, що
|
||||
валідація відповідає опублікованому npm package, без примусового Telegram E2E.
|
||||
має запускати свою матрицю package/update проти доставленого npm-пакета замість
|
||||
артефакта, зібраного з SHA. Надайте
|
||||
`evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
|
||||
валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
|
||||
Приклад:
|
||||
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
|
||||
- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження
|
||||
для кандидата package, поки релізна робота триває. Використовуйте `source=npm` для
|
||||
`openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`,
|
||||
щоб спакувати довірений branch/tag/SHA `package_ref` з поточним
|
||||
- Запустіть ручний workflow `Package Acceptance`, коли вам потрібне побічне підтвердження
|
||||
для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
|
||||
`openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`,
|
||||
щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним
|
||||
harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
|
||||
SHA-256; або `source=artifact` для tarball, завантаженого іншим run GitHub
|
||||
Actions. Workflow resolves кандидата в
|
||||
SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
|
||||
Actions. Workflow розв’язує кандидата до
|
||||
`package-under-test`, повторно використовує Docker E2E release scheduler проти цього
|
||||
tarball і може запускати Telegram QA проти того самого tarball з
|
||||
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані
|
||||
Docker lanes включають `published-upgrade-survivor`, артефакт package є кандидатом, а `published_upgrade_survivor_baseline` вибирає
|
||||
опублікований baseline.
|
||||
Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а `published_upgrade_survivor_baseline` вибирає
|
||||
опубліковану базову версію.
|
||||
Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
|
||||
Поширені профілі:
|
||||
- `smoke`: lanes install/channel/agent, gateway network і config reload
|
||||
- `package`: artifact-native lanes package/update/plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль package плюс MCP channels, cron/subagent cleanup,
|
||||
OpenAI web search і OpenWebUI
|
||||
- `full`: chunks Docker release-path з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для сфокусованого rerun
|
||||
- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
|
||||
для релізного кандидата. Ручні CI dispatches обходять changed
|
||||
- `smoke`: lanes для install/channel/agent, мережі Gateway і перезавантаження конфігурації
|
||||
- `package`: artifact-native lanes для package/update/plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль package плюс MCP channels, очищення cron/subagent,
|
||||
вебпошук OpenAI і OpenWebUI
|
||||
- `full`: фрагменти Docker release-path з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
|
||||
- Запустіть ручний workflow `CI` напряму, коли вам потрібне лише повне звичайне CI
|
||||
покриття для кандидата релізу. Ручні dispatch CI обходять changed
|
||||
scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
|
||||
contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
|
||||
docs checks, Python skills, Windows, macOS, Android і Control UI i18n
|
||||
перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n
|
||||
lanes.
|
||||
Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
|
||||
- Запустіть `pnpm qa:otel:smoke` під час валідації релізної telemetry. Він проганяє
|
||||
QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані імена trace
|
||||
span, обмежені attributes і редагування content/identifier без
|
||||
потреби в Opik, Langfuse або іншому зовнішньому collector.
|
||||
- Запускайте `pnpm release:check` перед кожним tagged release
|
||||
- Запустіть `OpenClaw Release Publish` для мутуючої послідовності публікації після того, як
|
||||
tag існує. Dispatch його з `release/YYYY.M.D` (або `main`, коли публікується
|
||||
tag, reachable з main), передайте release tag і успішний OpenClaw npm
|
||||
`preflight_run_id`, і залиште стандартну область публікації plugin
|
||||
`all-publishable`, якщо ви не виконуєте навмисно сфокусований repair. Цей
|
||||
workflow серіалізує plugin npm publish, plugin ClawHub publish і OpenClaw
|
||||
npm publish, щоб core package не було опубліковано раніше за його externalized
|
||||
- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє
|
||||
QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
|
||||
span, обмежені атрибути та редагування вмісту/ідентифікаторів без
|
||||
потреби в Opik, Langfuse або іншому зовнішньому колекторі.
|
||||
- Запускайте `pnpm release:check` перед кожним релізом із тегом
|
||||
- Запустіть `OpenClaw Release Publish` для мутувальної послідовності публікації після того, як
|
||||
тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте
|
||||
тег, досяжний з main), передайте релізний тег і успішний OpenClaw npm
|
||||
`preflight_run_id`, а scope публікації plugins за замовчуванням
|
||||
`all-publishable` залишайте, якщо тільки ви навмисно не виконуєте сфокусований ремонт. Workflow
|
||||
серіалізує публікацію plugin npm, публікацію plugin ClawHub і публікацію OpenClaw
|
||||
npm, щоб основний пакет не було опубліковано перед його екстерналізованими
|
||||
plugins.
|
||||
- Release checks тепер запускаються в окремому ручному workflow:
|
||||
`OpenClaw Release Checks`
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity lane плюс швидкий
|
||||
live Matrix profile і Telegram QA lane перед схваленням релізу. Live
|
||||
lanes використовують environment `qa-live-shared`; Telegram також використовує Convex CI
|
||||
credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний Matrix
|
||||
transport, media і E2EE inventory паралельно.
|
||||
- Cross-OS install і upgrade runtime validation є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які викликають
|
||||
reusable workflow
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму
|
||||
- Цей поділ навмисний: зберігайте реальний шлях npm release коротким,
|
||||
детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у своєму
|
||||
окремому lane, щоб вони не затримували й не блокували publish
|
||||
- Release checks із secrets слід dispatch через `Full Release
|
||||
lanes використовують середовище `qa-live-shared`; Telegram також використовує leases облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли вам потрібна повна інвентаризація Matrix
|
||||
transport, media та E2EE паралельно.
|
||||
- Cross-OS валідація runtime для встановлення та оновлення є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
|
||||
багаторазовий workflow
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
|
||||
- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким,
|
||||
детермінованим і зосередженим на артефактах, тоді як повільніші live checks залишаються у своєму
|
||||
окремому lane, щоб вони не затримували й не блокували публікацію
|
||||
- Release checks із секретами слід запускати через `Full Release
|
||||
Validation` або з workflow ref `main`/release, щоб логіка workflow і
|
||||
secrets залишалися контрольованими
|
||||
- `OpenClaw Release Checks` приймає branch, tag або повний commit SHA, доки
|
||||
resolved commit reachable з OpenClaw branch або release tag
|
||||
- validation-only preflight `OpenClaw NPM Release` також приймає поточний
|
||||
повний 40-символьний SHA commit workflow-branch без потреби в pushed tag
|
||||
- Цей шлях SHA призначений лише для validation і не може бути promoted у реальний publish
|
||||
секрети залишалися контрольованими
|
||||
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
|
||||
розв’язаний коміт досяжний з гілки OpenClaw або релізного тега
|
||||
- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
|
||||
повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тега
|
||||
- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для
|
||||
перевірки package metadata; реальний publish усе ще потребує справжнього release tag
|
||||
- Обидва workflows тримають реальний шлях publish і promotion на GitHub-hosted
|
||||
runners, тоді як немутуючий validation path може використовувати більші
|
||||
перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тега
|
||||
- Обидва workflows тримають реальний шлях публікації та promotion на GitHub-hosted
|
||||
runners, тоді як немутувальний шлях валідації може використовувати більші
|
||||
Blacksmith Linux runners
|
||||
- Цей workflow запускає
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
|
||||
- npm release preflight більше не чекає на окремий release checks lane
|
||||
- npm release preflight більше не чекає на окремий lane release checks
|
||||
- Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(або відповідний beta/correction tag) перед схваленням
|
||||
- Після npm publish запустіть
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(або відповідну beta/correction version), щоб перевірити опублікований шлях registry
|
||||
install у свіжому temp prefix
|
||||
(або відповідну beta/correction version), щоб перевірити шлях встановлення з опублікованого registry
|
||||
у свіжому тимчасовому prefix
|
||||
- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
|
||||
щоб перевірити installed-package onboarding, Telegram setup і реальний Telegram E2E
|
||||
проти опублікованого npm package з використанням спільного leased Telegram credential
|
||||
pool. Локальні одноразові запуски maintainer можуть omit Convex vars і передати три
|
||||
щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E
|
||||
проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram.
|
||||
Локальні одноразові перевірки maintainer можуть пропускати Convex vars і передавати три
|
||||
env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
|
||||
- Maintainers можуть запускати ту саму post-publish check з GitHub Actions через
|
||||
ручний workflow `NPM Telegram Beta E2E`. Він навмисно manual-only і
|
||||
не запускається на кожен merge.
|
||||
- Автоматизація release для maintainer тепер використовує preflight-then-promote:
|
||||
- реальний npm publish має пройти успішний npm `preflight_run_id`
|
||||
- реальний npm publish має бути dispatched з тієї самої branch `main` або
|
||||
ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
|
||||
не запускається під час кожного merge.
|
||||
- Автоматизація релізів maintainer тепер використовує preflight-then-promote:
|
||||
- реальна npm publish має пройти успішний npm `preflight_run_id`
|
||||
- реальна npm publish має запускатися з тієї самої гілки `main` або
|
||||
`release/YYYY.M.D`, що й успішний preflight run
|
||||
- stable npm releases стандартно використовують `beta`
|
||||
- stable npm publish може явно target `latest` через workflow input
|
||||
- token-based npm dist-tag mutation тепер живе в
|
||||
- стабільні npm-релізи за замовчуванням спрямовуються на `beta`
|
||||
- stable npm publish може явно націлюватися на `latest` через workflow input
|
||||
- token-based мутація npm dist-tag тепер живе в
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
з міркувань безпеки, тому що `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як
|
||||
публічний repo зберігає OIDC-only publish
|
||||
- public `macOS Release` є validation-only; коли tag існує лише на
|
||||
release branch, але workflow dispatched з `main`, встановіть
|
||||
публічний repo зберігає publish лише через OIDC
|
||||
- публічний `macOS Release` призначений лише для валідації; коли тег існує лише в
|
||||
release branch, але workflow запускається з `main`, задайте
|
||||
`public_release_branch=release/YYYY.M.D`
|
||||
- реальний private mac publish має пройти успішні private mac
|
||||
`preflight_run_id` і `validate_run_id`
|
||||
- реальні publish paths promote підготовлені артефакти замість повторної
|
||||
збірки
|
||||
- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
|
||||
- реальні шляхи публікації просувають підготовлені артефакти замість повторної
|
||||
їхньої збірки
|
||||
- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier
|
||||
також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб release corrections не могли непомітно залишити старіші global installs на
|
||||
щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
|
||||
базовому stable payload
|
||||
- npm release preflight fails closed, якщо tarball не містить одночасно
|
||||
- npm release preflight завершується закрито, якщо tarball не містить одночасно
|
||||
`dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
|
||||
щоб ми знову не відвантажили порожній browser dashboard
|
||||
- Post-publish verification також перевіряє, що опубліковані plugin entrypoints і
|
||||
package metadata присутні в установленому registry layout. Реліз, який
|
||||
відвантажує відсутні plugin runtime payloads, fails postpublish verifier і
|
||||
не може бути promoted до `latest`.
|
||||
- `pnpm test:install:smoke` також забезпечує budget npm pack `unpackedSize` для
|
||||
candidate update tarball, тож installer e2e ловить випадкове pack bloat
|
||||
до release publish path
|
||||
- Якщо release work торкалася CI planning, extension timing manifests або
|
||||
extension test matrices, згенеруйте повторно й перегляньте planner-owned
|
||||
outputs matrix `plugin-prerelease-extension-shard` з
|
||||
`.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
|
||||
описували застарілий CI layout
|
||||
- Готовність stable macOS release також включає updater surfaces:
|
||||
- GitHub release має зрештою містити спаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
щоб ми знову не доставили порожню browser dashboard
|
||||
- Post-publish verification також перевіряє, що опубліковані entrypoints plugins і
|
||||
package metadata присутні у встановленому registry layout. Реліз, який
|
||||
доставляє відсутні runtime payloads plugins, провалює postpublish verifier і
|
||||
не може бути просунутий до `latest`.
|
||||
- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до
|
||||
candidate update tarball, тож installer e2e ловить випадкове роздування пакета
|
||||
до шляху release publish
|
||||
- Якщо релізна робота торкалася CI planning, extension timing manifests або
|
||||
extension test matrices, перед схваленням перегенеруйте й перегляньте outputs матриці
|
||||
`plugin-prerelease-extension-shard`, якими володіє planner, з
|
||||
`.github/workflows/plugin-prerelease.yml`, щоб release notes не описували
|
||||
застарілий CI layout
|
||||
- Готовність стабільного macOS release також включає updater surfaces:
|
||||
- GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `appcast.xml` на `main` має вказувати на новий stable zip після publish
|
||||
- спакований app має зберігати non-debug bundle id, непорожній Sparkle feed
|
||||
URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
|
||||
для цієї release version
|
||||
- запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
|
||||
URL і `CFBundleVersion` на рівні або вище канонічної Sparkle build floor
|
||||
для цієї версії релізу
|
||||
|
||||
## Release test boxes
|
||||
## Релізні тестові бокси
|
||||
|
||||
`Full Release Validation` — це спосіб, яким operators запускають усі pre-release tests з
|
||||
однієї точки входу. Для pinned commit proof на швидкозмінній branch використовуйте
|
||||
helper, щоб кожен child workflow запускався з тимчасової branch, зафіксованої на target
|
||||
`Full Release Validation` — це спосіб, у який оператори запускають усі передрелізні тести з
|
||||
однієї точки входу. Для pinned commit proof на швидкозмінній гілці використовуйте
|
||||
helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на цільовому
|
||||
SHA:
|
||||
|
||||
```bash
|
||||
pnpm ci:full-release --sha <full-sha>
|
||||
```
|
||||
|
||||
Helper pushes `release-ci/<sha>-...`, dispatches `Full Release Validation`
|
||||
з цієї branch з `ref=<sha>`, перевіряє, що кожен child workflow `headSha`
|
||||
відповідає target, а потім видаляє тимчасову branch. Це запобігає випадковому підтвердженню
|
||||
новішого child run `main`.
|
||||
Helper пушить `release-ci/<sha>-...`, запускає `Full Release Validation`
|
||||
з цієї гілки з `ref=<sha>`, перевіряє, що кожен дочірній workflow `headSha`
|
||||
відповідає цільовому, а потім видаляє тимчасову гілку. Це запобігає випадковому підтвердженню
|
||||
новішого дочірнього запуску `main`.
|
||||
|
||||
Для валідації release branch або tag запустіть його з довіреного workflow
|
||||
ref `main` і передайте release branch або tag як `ref`:
|
||||
Для валідації release branch або tag запускайте його з довіреного workflow
|
||||
ref `main` і передавайте release branch або tag як `ref`:
|
||||
|
||||
```bash
|
||||
gh workflow run full-release-validation.yml \
|
||||
@ -290,46 +290,48 @@ gh workflow run full-release-validation.yml \
|
||||
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
|
||||
```
|
||||
|
||||
Робочий процес розв’язує цільовий ref, запускає ручний `CI` з
|
||||
Робочий процес визначає цільовий ref, запускає ручний `CI` з
|
||||
`target_ref=<release-ref>`, запускає `OpenClaw Release Checks`, готує
|
||||
батьківський артефакт `release-package-under-test` для перевірок, орієнтованих
|
||||
на пакети, і запускає окремий пакетний Telegram E2E, коли `release_profile=full` з
|
||||
`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
|
||||
Checks` розгалужується на install smoke, кросплатформні релізні перевірки, live/E2E Docker
|
||||
покриття релізного шляху, Package Acceptance з пакетним Telegram QA, QA Lab
|
||||
parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
|
||||
підсумок `Full Release Validation`
|
||||
показує `normal_ci` і `release_checks` як успішні. У режимі full/all
|
||||
дочірній `npm_telegram` також має бути успішним; поза full/all його пропускають,
|
||||
якщо не було надано опублікований `npm_telegram_package_spec`. Фінальний
|
||||
підсумок верифікатора містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release
|
||||
manager міг бачити поточний критичний шлях без завантаження логів.
|
||||
Див. [Повна релізна валідація](/uk/reference/full-release-validation) для
|
||||
повної матриці етапів, точних назв завдань workflow, відмінностей між stable і full
|
||||
профілями, артефактів і точкових механізмів повторного запуску.
|
||||
Дочірні workflow запускаються з довіреного ref, який запускає `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
|
||||
старішу релізну гілку або тег. Окремого входу Full Release Validation
|
||||
workflow-ref немає; вибирайте довірений harness, вибираючи ref запуску workflow.
|
||||
Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомій `main`;
|
||||
сирі SHA комітів не можуть бути refs для workflow dispatch, тому використовуйте
|
||||
батьківський артефакт `release-package-under-test` для перевірок, пов’язаних із
|
||||
пакунком, і запускає автономний package Telegram E2E, коли `release_profile=full`
|
||||
з `rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
|
||||
Checks` розгалужується на install smoke, cross-OS release checks, покриття
|
||||
release-path для live/E2E Docker, Package Acceptance з package QA для Telegram,
|
||||
QA Lab parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді,
|
||||
коли підсумок `Full Release Validation`
|
||||
показує `normal_ci` і `release_checks` як успішні. У режимі full/all дочірній
|
||||
`npm_telegram` також має бути успішним; поза full/all його пропускають, якщо не
|
||||
було надано опублікований `npm_telegram_package_spec`. Підсумок фінального
|
||||
верифікатора містить таблиці найповільніших завдань для кожного дочірнього
|
||||
запуску, щоб менеджер релізу міг бачити поточний критичний шлях без завантаження
|
||||
логів.
|
||||
Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для повної
|
||||
матриці етапів, точних назв завдань workflow, відмінностей між профілями stable
|
||||
і full, артефактів і цільових ідентифікаторів повторного запуску.
|
||||
Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на старішу
|
||||
release-гілку або тег. Окремого вхідного параметра workflow-ref для Full Release
|
||||
Validation немає; вибирайте довірений harness, вибираючи ref запуску workflow.
|
||||
Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомій
|
||||
`main`; сирі commit SHA не можуть бути workflow dispatch refs, тому використовуйте
|
||||
`pnpm ci:full-release --sha <sha>`, щоб створити закріплену тимчасову гілку.
|
||||
|
||||
Використовуйте `release_profile`, щоб вибрати ширину live/provider:
|
||||
|
||||
- `minimum`: найшвидший release-critical OpenAI/core live і Docker шлях
|
||||
- `stable`: minimum плюс stable provider/backend покриття для затвердження релізу
|
||||
- `full`: stable плюс широке advisory provider/media покриття
|
||||
- `minimum`: найшвидший release-critical OpenAI/core live і Docker path
|
||||
- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
|
||||
- `full`: stable плюс broad advisory provider/media coverage
|
||||
|
||||
`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати цільовий
|
||||
ref як `release-package-under-test`, і повторно використовує цей артефакт як у
|
||||
release-path Docker перевірках, так і в Package Acceptance. Це тримає всі
|
||||
package-facing бокси на тих самих байтах і уникає повторних збірок пакета.
|
||||
Кросплатформний OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
|
||||
задано repo/org змінну, інакше `openai/gpt-5.4`, бо ця lane
|
||||
доводить встановлення пакета, onboarding, запуск Gateway і один live agent turn,
|
||||
а не бенчмаркує найповільнішу модель за замовчуванням. Ширша live provider
|
||||
matrix лишається місцем для model-specific покриття.
|
||||
`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз
|
||||
визначити цільовий ref як `release-package-under-test`, і повторно використовує
|
||||
цей артефакт як у release-path Docker checks, так і в Package Acceptance. Це
|
||||
утримує всі package-facing box на однакових байтах і уникає повторних збірок
|
||||
пакунка.
|
||||
Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
|
||||
задано repo/org variable, інакше `openai/gpt-5.4`, тому що ця lane доводить
|
||||
інсталяцію пакунка, onboarding, запуск Gateway і один live agent turn, а не
|
||||
бенчмарк найповільнішої моделі за замовчуванням. Ширша матриця live provider
|
||||
залишається місцем для model-specific coverage.
|
||||
|
||||
Використовуйте ці варіанти залежно від етапу релізу:
|
||||
|
||||
@ -361,41 +363,45 @@ gh workflow run full-release-validation.yml \
|
||||
-f npm_telegram_provider_mode=mock-openai
|
||||
```
|
||||
|
||||
Не використовуйте повну umbrella як перший повторний запуск після точкового виправлення. Якщо один box
|
||||
падає, використовуйте невдалий дочірній workflow, job, Docker lane, package profile, model
|
||||
provider або QA lane для наступного доказу. Запускайте повну umbrella знову лише тоді,
|
||||
коли виправлення змінило спільну релізну оркестрацію або зробило попередні all-box докази
|
||||
застарілими. Фінальний верифікатор umbrella повторно перевіряє записані child workflow run
|
||||
ids, тому після успішного повторного запуску дочірнього workflow перезапускайте лише невдалий
|
||||
батьківський job `Verify full validation`.
|
||||
Не використовуйте повну umbrella як перший повторний запуск після цільового
|
||||
виправлення. Якщо один box не проходить, використовуйте failed child workflow,
|
||||
job, Docker lane, package profile, model provider або QA lane для наступного
|
||||
доказу. Запускайте повну umbrella знову лише тоді, коли виправлення змінило
|
||||
спільну release orchestration або зробило попередні all-box докази застарілими.
|
||||
Фінальний верифікатор umbrella повторно перевіряє записані ідентифікатори
|
||||
запусків дочірніх workflow, тому після успішного повторного запуску дочірнього
|
||||
workflow повторно запускайте лише failed parent job `Verify full validation`.
|
||||
|
||||
Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній
|
||||
запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
|
||||
запускає лише release-only дочірній Plugin, `release-checks` запускає кожен release
|
||||
box, а вужчі release groups — це `install-smoke`, `cross-os`,
|
||||
`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`.
|
||||
Точкові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски
|
||||
з `release_profile=full` використовують пакетний артефакт release-checks.
|
||||
Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` є справжнім
|
||||
запуском release-candidate, `ci` запускає лише дочірній normal CI,
|
||||
`plugin-prerelease` запускає лише release-only plugin child, `release-checks`
|
||||
запускає кожен release box, а вужчі release groups — це `install-smoke`,
|
||||
`cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і
|
||||
`npm-telegram`.
|
||||
Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`;
|
||||
full/all запуски з `release_profile=full` використовують package artifact із
|
||||
release-checks.
|
||||
|
||||
### Vitest
|
||||
|
||||
Vitest box — це ручний дочірній workflow `CI`. Ручний CI навмисно
|
||||
обходить changed scoping і примусово запускає звичайний тестовий граф для release
|
||||
candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
|
||||
Vitest box — це ручний дочірній workflow `CI`. Ручний CI навмисно обходить
|
||||
changed scoping і примусово виконує звичайний test graph для release candidate:
|
||||
Linux Node shards, bundled-plugin shards, channel contracts, Node 22
|
||||
compatibility, `check`, `check-additional`, build smoke, docs checks, Python
|
||||
Skills, Windows, macOS, Android і Control UI i18n.
|
||||
skills, Windows, macOS, Android і Control UI i18n.
|
||||
|
||||
Використовуйте цей box, щоб відповісти: «чи пройшло дерево source повний звичайний test suite?»
|
||||
Це не те саме, що release-path продуктова валідація. Докази, які треба зберегти:
|
||||
Використовуйте цей box, щоб відповісти: «чи пройшло дерево вихідного коду повний
|
||||
звичайний набір тестів?» Це не те саме, що release-path product validation.
|
||||
Докази, які слід зберегти:
|
||||
|
||||
- підсумок `Full Release Validation`, що показує URL запущеного `CI` run
|
||||
- зелений `CI` run на точному target SHA
|
||||
- назви невдалих або повільних shards із CI jobs під час розслідування регресій
|
||||
- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
|
||||
- зелений `CI` run на точному цільовому SHA
|
||||
- назви failed або slow shard із CI jobs під час дослідження регресій
|
||||
- артефакти часу Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
|
||||
запуск потребує аналізу продуктивності
|
||||
|
||||
Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але
|
||||
не потрібні Docker, QA Lab, live, cross-OS або package boxes:
|
||||
Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal
|
||||
CI, але не Docker, QA Lab, live, cross-OS або package boxes:
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
@ -403,16 +409,16 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
|
||||
### Docker
|
||||
|
||||
Docker box живе в `OpenClaw Release Checks` через
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
|
||||
workflow `install-smoke`. Він валідовує release candidate через упаковані
|
||||
Docker середовища, а не лише source-level тести.
|
||||
Docker box міститься в `OpenClaw Release Checks` через
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode workflow
|
||||
`install-smoke`. Він перевіряє release candidate через packaged Docker
|
||||
environments, а не лише source-level tests.
|
||||
|
||||
Release Docker покриття включає:
|
||||
Release Docker coverage включає:
|
||||
|
||||
- повний install smoke з увімкненим повільним Bun global install smoke
|
||||
- підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR,
|
||||
root/gateway і installer/Bun smoke jobs, що запускаються як окремі install-smoke
|
||||
root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke
|
||||
shards
|
||||
- repository E2E lanes
|
||||
- release-path Docker chunks: `core`, `package-update-openai`,
|
||||
@ -422,54 +428,54 @@ Release Docker покриття включає:
|
||||
`plugins-runtime-install-c`, `plugins-runtime-install-d`,
|
||||
`plugins-runtime-install-e`, `plugins-runtime-install-f`,
|
||||
`plugins-runtime-install-g` і `plugins-runtime-install-h`
|
||||
- OpenWebUI покриття всередині chunk `plugins-runtime-services`, коли запитано
|
||||
- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано
|
||||
- розділені bundled plugin install/uninstall lanes
|
||||
`bundled-plugin-install-uninstall-0` through
|
||||
`bundled-plugin-install-uninstall-0` до
|
||||
`bundled-plugin-install-uninstall-23`
|
||||
- live/E2E provider suites і Docker live model coverage, коли release checks
|
||||
включають live suites
|
||||
|
||||
Використовуйте Docker артефакти перед повторним запуском. Release-path scheduler завантажує
|
||||
`.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
|
||||
phase timings, scheduler plan JSON і rerun commands. Для точкового відновлення
|
||||
Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler
|
||||
завантажує `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
|
||||
phase timings, scheduler plan JSON і rerun commands. Для цільового відновлення
|
||||
використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
|
||||
повторного запуску всіх release chunks. Згенеровані rerun commands включають попередній
|
||||
`package_artifact_run_id` і підготовлені Docker image inputs, коли доступні, щоб
|
||||
невдала lane могла повторно використати той самий tarball і GHCR images.
|
||||
повторного запуску всіх release chunks. Згенеровані rerun commands включають
|
||||
попередній `package_artifact_run_id` і підготовлені Docker image inputs, коли
|
||||
вони доступні, тому failed lane може повторно використати той самий tarball і
|
||||
GHCR images.
|
||||
|
||||
### QA Lab
|
||||
|
||||
QA Lab box також є частиною `OpenClaw Release Checks`. Це агентний
|
||||
behavior і channel-level release gate, окремий від Vitest і Docker
|
||||
package mechanics.
|
||||
QA Lab box також є частиною `OpenClaw Release Checks`. Це release gate для
|
||||
agentic behavior і channel-level, окремий від Vitest і Docker package mechanics.
|
||||
|
||||
Release QA Lab покриття включає:
|
||||
Release QA Lab coverage включає:
|
||||
|
||||
- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6
|
||||
baseline за допомогою agentic parity pack
|
||||
- швидкий live Matrix QA profile з використанням середовища `qa-live-shared`
|
||||
- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6 baseline за
|
||||
допомогою agentic parity pack
|
||||
- fast live Matrix QA profile з використанням середовища `qa-live-shared`
|
||||
- live Telegram QA lane з використанням Convex CI credential leases
|
||||
- `pnpm qa:otel:smoke`, коли release telemetry потребує явного local proof
|
||||
- `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу
|
||||
|
||||
Використовуйте цей box, щоб відповісти: «чи реліз поводиться коректно в QA scenarios і
|
||||
live channel flows?» Зберігайте artifact URLs для parity, Matrix і Telegram
|
||||
lanes під час затвердження релізу. Повне Matrix покриття лишається доступним як
|
||||
ручний sharded QA-Lab run, а не default release-critical lane.
|
||||
Використовуйте цей box, щоб відповісти: «чи поводиться реліз правильно в QA
|
||||
scenarios і live channel flows?» Зберігайте URL артефактів для parity, Matrix і
|
||||
Telegram lanes під час схвалення релізу. Full Matrix coverage залишається
|
||||
доступним як ручний sharded QA-Lab run, а не як default release-critical lane.
|
||||
|
||||
### Package
|
||||
### Пакунок
|
||||
|
||||
Package box — це installable-product gate. Його підтримують
|
||||
Package box — це gate для installable-product. Він підтримується
|
||||
`Package Acceptance` і resolver
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
|
||||
candidate у tarball `package-under-test`, який споживає Docker E2E, валідовує
|
||||
package inventory, записує package version і SHA-256 та тримає
|
||||
workflow harness ref окремо від package source ref.
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує candidate
|
||||
у tarball `package-under-test`, який споживає Docker E2E, перевіряє package
|
||||
inventory, записує package version і SHA-256, а також тримає workflow harness ref
|
||||
окремо від package source ref.
|
||||
|
||||
Підтримувані джерела candidate:
|
||||
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release
|
||||
version
|
||||
- `source=ref`: пакує довірену гілку `package_ref`, тег або повний commit SHA
|
||||
- `source=ref`: пакує довірену `package_ref` branch, tag або full commit SHA
|
||||
з вибраним `workflow_ref` harness
|
||||
- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256`
|
||||
- `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run
|
||||
@ -481,35 +487,36 @@ workflow harness ref окремо від package source ref.
|
||||
`published_upgrade_survivor_scenarios=reported-issues` і
|
||||
`telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale
|
||||
plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram
|
||||
package QA проти того самого розв’язаного tarball. Upgrade matrix покриває кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте
|
||||
Package Acceptance з `source=npm` для вже shipped candidate або
|
||||
package QA проти того самого resolved tarball. Матриця upgrade охоплює кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте
|
||||
Package Acceptance з `source=npm` для вже випущеного candidate або
|
||||
`source=ref`/`source=artifact` для SHA-backed local npm tarball перед
|
||||
публікацією. Це GitHub-native
|
||||
заміна для більшості package/update покриття, яке раніше вимагало
|
||||
Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
|
||||
installer і platform behavior, але package/update product validation має
|
||||
надавати перевагу Package Acceptance.
|
||||
заміна для більшості package/update coverage, що раніше вимагало Parallels.
|
||||
Cross-OS release checks усе ще важливі для OS-specific onboarding, installer і
|
||||
platform behavior, але package/update product validation має надавати перевагу
|
||||
Package Acceptance.
|
||||
|
||||
Канонічний checklist для update і plugin validation —
|
||||
[Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). Використовуйте його, коли
|
||||
вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить
|
||||
plugin install/update, doctor cleanup або published-package migration change.
|
||||
Вичерпна published update migration з кожного stable пакета `2026.4.23+` — це
|
||||
окремий ручний workflow `Update Migration`, а не частина Full Release CI.
|
||||
[Тестування оновлень і плагінів](/uk/help/testing-updates-plugins). Використовуйте
|
||||
його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check
|
||||
lane доводить plugin install/update, doctor cleanup або published-package
|
||||
migration change.
|
||||
Вичерпна published update migration з кожного stable пакунка `2026.4.23+` є
|
||||
окремим ручним workflow `Update Migration`, а не частиною Full Release CI.
|
||||
|
||||
Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до
|
||||
`2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих
|
||||
у npm: private QA inventory entries, відсутні в tarball, відсутній
|
||||
`gateway install --wrapper`, відсутні patch files у tarball-derived git
|
||||
Legacy package-acceptance leniency навмисно обмежена в часі. Пакунки до
|
||||
`2026.4.25` включно можуть використовувати compatibility path для metadata gaps,
|
||||
уже опублікованих у npm: private QA inventory entries, відсутні в tarball,
|
||||
відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git
|
||||
fixture, відсутній persisted `update.channel`, legacy plugin install-record
|
||||
locations, відсутня marketplace install-record persistence і config metadata
|
||||
migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати
|
||||
про local build metadata stamp files, які вже були shipped. Пізніші пакети
|
||||
мають задовольняти сучасні package contracts; ті самі gaps провалюють release
|
||||
validation.
|
||||
migration під час `plugins update`. Опублікований пакунок `2026.4.26` може
|
||||
попереджати про local build metadata stamp files, які вже були випущені. Пізніші
|
||||
пакунки мають задовольняти modern package contracts; ті самі gaps провалюють
|
||||
release validation.
|
||||
|
||||
Використовуйте ширші Package Acceptance profiles, коли release question стосується
|
||||
фактичного installable package:
|
||||
реального installable package:
|
||||
|
||||
```bash
|
||||
gh workflow run package-acceptance.yml \
|
||||
@ -523,35 +530,32 @@ gh workflow run package-acceptance.yml \
|
||||
|
||||
Поширені package profiles:
|
||||
|
||||
- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway та
|
||||
перезавантаження конфігурації
|
||||
- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типове значення
|
||||
release-check
|
||||
- `product`: `package` плюс канали MCP, очищення cron/субагентів, вебпошук OpenAI
|
||||
та OpenWebUI
|
||||
- `full`: фрагменти шляху Docker-релізу з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
|
||||
- `smoke`: швидке встановлення пакета/каналу/агента, мережа Gateway і смуги перезавантаження конфігурації
|
||||
- `package`: контракти встановлення/оновлення/пакета Plugin без live ClawHub; це типовий release-check
|
||||
- `product`: `package` плюс канали MCP, очищення cron/subagent, вебпошук OpenAI і OpenWebUI
|
||||
- `full`: частини шляху Docker-релізу з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для цільових повторних запусків
|
||||
|
||||
Для підтвердження Telegram кандидата пакета увімкніть `telegram_mode=mock-openai` або
|
||||
`telegram_mode=live-frontier` у Package Acceptance. Робочий процес передає
|
||||
розв’язаний tarball `package-under-test` у лінію Telegram; окремий робочий процес
|
||||
Telegram все ще приймає опубліковану npm-специфікацію для перевірок після публікації.
|
||||
Для підтвердження кандидата пакета в Telegram увімкніть `telegram_mode=mock-openai` або
|
||||
`telegram_mode=live-frontier` у Package Acceptance. Workflow передає
|
||||
розв’язаний tarball `package-under-test` у смугу Telegram; окремий
|
||||
workflow Telegram усе ще приймає опубліковану npm-специфікацію для перевірок після публікації.
|
||||
|
||||
## Автоматизація публікації релізу
|
||||
|
||||
`OpenClaw Release Publish` є звичайною змінною точкою входу для публікації. Він
|
||||
оркеструє робочі процеси trusted-publisher у порядку, потрібному для релізу:
|
||||
`OpenClaw Release Publish` є звичайною мутувальною точкою входу для публікації. Він
|
||||
оркеструє workflows довіреного видавця в порядку, потрібному релізу:
|
||||
|
||||
1. Витягнути тег релізу та визначити його SHA коміту.
|
||||
2. Перевірити, що тег досяжний з `main` або `release/*`.
|
||||
1. Отримати release tag і визначити його commit SHA.
|
||||
2. Перевірити, що tag досяжний із `main` або `release/*`.
|
||||
3. Запустити `pnpm plugins:sync:check`.
|
||||
4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і
|
||||
`ref=<release-sha>`.
|
||||
5. Запустити `Plugin ClawHub Release` з тією самою областю та SHA.
|
||||
6. Запустити `OpenClaw NPM Release` з тегом релізу, npm dist-tag і
|
||||
5. Запустити `Plugin ClawHub Release` з тією самою областю дії та SHA.
|
||||
6. Запустити `OpenClaw NPM Release` з release tag, npm dist-tag і
|
||||
збереженим `preflight_run_id`.
|
||||
|
||||
Приклад публікації бета-версії:
|
||||
Приклад публікації beta:
|
||||
|
||||
```bash
|
||||
gh workflow run openclaw-release-publish.yml \
|
||||
@ -561,7 +565,7 @@ gh workflow run openclaw-release-publish.yml \
|
||||
-f npm_dist_tag=beta
|
||||
```
|
||||
|
||||
Стабільна публікація до типового бета-dist-tag:
|
||||
Стабільна публікація в типовий beta dist-tag:
|
||||
|
||||
```bash
|
||||
gh workflow run openclaw-release-publish.yml \
|
||||
@ -581,91 +585,91 @@ gh workflow run openclaw-release-publish.yml \
|
||||
-f npm_dist_tag=latest
|
||||
```
|
||||
|
||||
Використовуйте нижчорівневі робочі процеси `Plugin NPM Release` і `Plugin ClawHub Release`
|
||||
лише для сфокусованого виправлення або повторної публікації. Для виправлення вибраного plugin передайте
|
||||
Використовуйте нижчорівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release`
|
||||
лише для цільового ремонту або повторної публікації. Для ремонту вибраного Plugin передайте
|
||||
`plugin_publish_scope=selected` і `plugins=@openclaw/name` до
|
||||
`OpenClaw Release Publish`, або запускайте дочірній робочий процес безпосередньо, коли
|
||||
`OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли
|
||||
пакет OpenClaw не має бути опублікований.
|
||||
|
||||
## Вхідні дані робочого процесу NPM
|
||||
## Вхідні параметри workflow NPM
|
||||
|
||||
`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:
|
||||
`OpenClaw NPM Release` приймає такі вхідні параметри, керовані оператором:
|
||||
|
||||
- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
|
||||
- `tag`: обов’язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1` або
|
||||
`v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
|
||||
повний 40-символьний SHA коміту гілки робочого процесу для preflight лише з валідацією
|
||||
- `preflight_only`: `true` лише для валідації/збірки/пакета, `false` для
|
||||
повний 40-символьний commit SHA гілки workflow для preflight лише з перевіркою
|
||||
- `preflight_only`: `true` для лише перевірки/збірки/пакування, `false` для
|
||||
справжнього шляху публікації
|
||||
- `preflight_run_id`: обов’язковий у справжньому шляху публікації, щоб робочий процес повторно використовував
|
||||
- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб workflow повторно використав
|
||||
підготовлений tarball з успішного preflight-запуску
|
||||
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типово `beta`
|
||||
|
||||
`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані:
|
||||
`OpenClaw Release Publish` приймає такі вхідні параметри, керовані оператором:
|
||||
|
||||
- `tag`: обов’язковий тег релізу; має вже існувати
|
||||
- `preflight_run_id`: ідентифікатор успішного preflight-запуску `OpenClaw NPM Release`;
|
||||
- `tag`: обов’язковий release tag; уже має існувати
|
||||
- `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`;
|
||||
обов’язковий, коли `publish_openclaw_npm=true`
|
||||
- `npm_dist_tag`: цільовий npm-тег для пакета OpenClaw
|
||||
- `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише
|
||||
для сфокусованого виправлення
|
||||
для цільового ремонту
|
||||
- `plugins`: розділені комами назви пакетів `@openclaw/*`, коли
|
||||
`plugin_publish_scope=selected`
|
||||
- `publish_openclaw_npm`: типово `true`; встановлюйте `false` лише під час використання
|
||||
робочого процесу як оркестратора виправлення тільки для plugin
|
||||
- `publish_openclaw_npm`: типово `true`; встановлюйте `false` лише коли використовуєте
|
||||
workflow як оркестратор ремонту тільки Plugin
|
||||
|
||||
`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:
|
||||
`OpenClaw Release Checks` приймає такі вхідні параметри, керовані оператором:
|
||||
|
||||
- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки із секретами
|
||||
вимагають, щоб визначений коміт був досяжний з гілки OpenClaw або
|
||||
тегу релізу.
|
||||
- `ref`: гілка, tag або повний commit SHA для перевірки. Перевірки,
|
||||
що містять секрети, вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або
|
||||
release tag.
|
||||
|
||||
Правила:
|
||||
|
||||
- Стабільні теги та теги виправлень можуть публікуватися або до `beta`, або до `latest`
|
||||
- Бета-теги попереднього релізу можуть публікуватися лише до `beta`
|
||||
- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли
|
||||
- Стабільні та корекційні tags можуть публікуватися або до `beta`, або до `latest`
|
||||
- Beta prerelease tags можуть публікуватися лише до `beta`
|
||||
- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли
|
||||
`preflight_only=true`
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди є
|
||||
лише валідаційними
|
||||
- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час preflight;
|
||||
робочий процес перевіряє ці метадані перед продовженням публікації
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди
|
||||
лише перевіряють
|
||||
- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
|
||||
workflow перевіряє ці metadata перед продовженням публікації
|
||||
|
||||
## Послідовність стабільного npm-релізу
|
||||
|
||||
Під час підготовки стабільного npm-релізу:
|
||||
|
||||
1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
|
||||
- До існування тегу можна використати поточний повний SHA коміту гілки робочого процесу
|
||||
для валідаційного dry run робочого процесу preflight
|
||||
- До появи tag можна використати поточний повний commit SHA гілки workflow
|
||||
для пробного запуску preflight workflow лише з перевіркою
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
|
||||
коли ви навмисно хочете пряме стабільне публікування
|
||||
3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному
|
||||
SHA коміту, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
|
||||
Matrix і покриття Telegram з одного ручного робочого процесу
|
||||
коли ви навмисно хочете пряму стабільну публікацію
|
||||
3. Запустіть `Full Release Validation` на release branch, release tag або повному
|
||||
commit SHA, коли вам потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
|
||||
Matrix і покриття Telegram з одного ручного workflow
|
||||
4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, запустіть
|
||||
ручний робочий процес `CI` на ref релізу натомість
|
||||
ручний workflow `CI` на release ref натомість
|
||||
5. Збережіть успішний `preflight_run_id`
|
||||
6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag`
|
||||
і збереженим `preflight_run_id`; він публікує externalized plugins до npm
|
||||
і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm
|
||||
і ClawHub перед просуванням npm-пакета OpenClaw
|
||||
7. Якщо реліз потрапив до `beta`, використовуйте приватний робочий процес
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
для просування цієї стабільної версії з `beta` до `latest`
|
||||
8. Якщо реліз навмисно опублікований безпосередньо до `latest`, а `beta`
|
||||
має негайно наслідувати ту саму стабільну збірку, використовуйте той самий приватний
|
||||
робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
|
||||
self-healing синхронізації перемістити `beta` пізніше
|
||||
7. Якщо реліз потрапив у `beta`, використайте приватний
|
||||
workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
|
||||
щоб просунути цю стабільну версію з `beta` до `latest`
|
||||
8. Якщо реліз навмисно опубліковано безпосередньо до `latest` і `beta`
|
||||
має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний
|
||||
workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
|
||||
самовідновлювальній синхронізації перемістити `beta` пізніше
|
||||
|
||||
Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, тому що вона все ще
|
||||
вимагає `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only публікацію.
|
||||
Мутація dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона все ще
|
||||
потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
|
||||
|
||||
Це робить як шлях прямої публікації, так і шлях beta-first просування
|
||||
Це зберігає і шлях прямої публікації, і шлях beta-first promotion
|
||||
задокументованими та видимими для оператора.
|
||||
|
||||
Якщо супровідник мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
|
||||
CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; утримання цього всередині tmux робить підказки,
|
||||
сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста.
|
||||
Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
|
||||
CLI (`op`) лише всередині спеціальної сесії tmux. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; утримання його всередині tmux робить prompts,
|
||||
alerts і обробку OTP спостережуваними та запобігає повторним alerts на хості.
|
||||
|
||||
## Публічні посилання
|
||||
|
||||
@ -679,7 +683,7 @@ CLI (`op`) лише всередині виділеної tmux-сесії. Не
|
||||
- [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
|
||||
- [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
|
||||
|
||||
Супровідники використовують приватну документацію релізу в
|
||||
Maintainers використовують приватну документацію релізів у
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
для фактичного runbook.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user