Повна перевірка випуску

Full Release Validation — це парасольковий процес релізу: єдина ручна точка входу для перевірки перед релізом. Основна робота виконується в дочірніх робочих процесах, щоб невдале середовище можна було перезапустити без повторного запуску всього релізу. Запускайте його з довіреного посилання на робочий процес, зазвичай main, і передавайте гілку релізу, тег або повний SHA коміту як ref:

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.PATCH \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

provider також приймає anthropic або minimax для онбордингу в різних ОС і наскрізного кроку агента. Повторно використовувані дочірні завдання визначають середовище викликаного робочого процесу з job.workflow_repository і job.workflow_sha, тоді як вхідний параметр ref вибирає тестований кандидат. Це дає змогу використовувати поточну довірену логіку перевірки під час перевірки старішої гілки релізу або тегу. Кожен запущений дочірній процес має повідомляти той самий SHA робочого процесу, що й батьківський запуск Full Release Validation. Якщо main зміниться між запуском батьківського й дочірніх процесів, парасольковий процес безпечно завершується помилкою, навіть якщо сам дочірній процес успішний. Для незмінної перевірки конкретного коміту використовуйте pnpm ci:full-release --sha <target-sha>. Допоміжний засіб створює тимчасове посилання release-ci/*, закріплене за поточним довіреним origin/main, передає цільовий SHA лише як кандидат ref, повторно використовує суворі докази для точної цілі, якщо вони доступні, і видаляє посилання після перевірки. Передайте -f reuse_evidence=false, щоб примусово виконати новий запуск, або --workflow-sha <trusted-main-sha>, щоб вибрати старіший коміт робочого процесу, який усе ще доступний із поточного origin/main. Сам робочий процес ніколи не створює й не оновлює посилання репозиторію. release_profile=stable і release_profile=full завжди запускають вичерпне тривале тестування в реальному середовищі та Docker. Передайте run_release_soak=true, щоб включити ті самі смуги тривалого тестування для профілю beta. Стабільна публікація відхиляє маніфест перевірки без цього тривалого тестування та блокувальних доказів продуктивності продукту. Перевірка пакета зазвичай збирає архів кандидата з визначеного ref, зокрема для запусків за повним SHA, ініційованих через pnpm ci:full-release. Після публікації бета-версії передайте release_package_spec=openclaw@YYYY.M.PATCH-beta.N, щоб повторно використати опублікований пакет npm у перевірках релізу, перевірці пакета, перевірках у різних ОС, Docker-перевірках шляху релізу та пакетній перевірці Telegram. Використовуйте package_acceptance_package_spec лише тоді, коли перевірка пакета має навмисно перевіряти інший пакет. Смуга перевірки опублікованого пакета Plugin Codex дотримується того самого стану: для опублікованих значень release_package_spec визначається codex_plugin_spec=npm:@openclaw/codex@<version>; запуски за SHA або артефактом пакують extensions/codex із вибраного посилання; оператори також можуть безпосередньо задавати codex_plugin_spec для джерел Plugin типу npm:, npm-pack: або git:. Смуга надає явне схвалення встановлення Codex CLI, потрібне цьому Plugin, після чого виконує попередню перевірку Codex CLI та кроки агента OpenAI у тому самому сеансі.

Етапи верхнього рівня

Для rerun_group=all спочатку виконується завдання Check for reusable validation evidence: воно шукає найновішу попередню успішну повну перевірку для точно того самого цільового SHA, профілю релізу, фактичного налаштування тривалого тестування та вхідних параметрів перевірки. Якщо такі докази існують, усі смуги пропускаються, а парасольковий засіб перевірки повторно перевіряє незмінний батьківський артефакт, дочірні запуски та журнали запуску. Це лише відновлення повторного запуску того самого кандидата; воно не дозволяє повторно використовувати докази для іншого SHA. Для зміненого кандидата повторно запустіть кожну перевірку пакета, артефакту, встановлення, Docker або провайдера, якої стосуються ці зміни. Передайте reuse_evidence=false, щоб примусово виконати новий повний запуск. Повторне використання доказів виконується лише з main або канонічного закріпленого за SHA посилання release-ci/*, коміт робочого процесу якого залишається в довіреній історії main; інші посилання робочого процесу запускають вибрані смуги заново. Також для rerun_group=all завдання Verify Docker runtime image assets збирає ціль Docker runtime-assets із OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Воно виконується паралельно з іншими етапами та контролюється парасольковим засобом перевірки; смуги більше не очікують на нього перед запуском. Вужче значення rerun_group пропускає цю попередню перевірку.

Етап	Відомості
Визначення цілі	Завдання: `Resolve target ref` Дочірній робочий процес: немає Перевіряє: визначає гілку релізу, тег або повний SHA коміту й записує вибрані вхідні параметри. Повторний запуск: у разі помилки повторно запустіть парасольковий процес.
Попередня перевірка ресурсів Docker	Завдання: `Verify Docker runtime image assets` Дочірній робочий процес: немає Перевіряє: ціль збірки Docker `runtime-assets` і далі успішно збирається до запуску будь-якого іншого етапу. Виконується лише для `rerun_group=all`. Повторний запуск: повторно запустіть парасольковий процес із `rerun_group=all`.
Vitest і звичайний CI	Завдання: `Run normal full CI` Дочірній робочий процес: `CI` Перевіряє: повний граф CI, запущений вручну для цільового посилання, включно зі смугами Linux Node, сегментами вбудованих Plugin, сегментами контрактів Plugin і каналів, сумісністю з Node 22, `check-`, `check-additional-`, швидкими перевірками зібраних артефактів, перевірками документації, Python skills, Windows, macOS, локалізацією Control UI та Android через парасольковий процес. Повторний запуск: `rerun_group=ci`.
Передрелізна перевірка Plugin	Завдання: `Run plugin prerelease validation` Дочірній робочий процес: `Plugin Prerelease` Перевіряє: статичні перевірки Plugin лише для релізу, агентне покриття Plugin, повні пакетні сегменти Plugin, передрелізні смуги Docker для Plugin і неблокувальний артефакт `plugin-inspector-advisory` для сортування проблем сумісності. Повторний запуск: `rerun_group=plugin-prerelease`.
Перевірки релізу	Завдання: `Run release/live/Docker/QA validation` Дочірній робочий процес: `OpenClaw Release Checks` Перевіряє: швидку перевірку встановлення, перевірки пакета в різних ОС, перевірку пакета, відповідність QA Lab, перевірки Matrix і Telegram у реальному середовищі. Стабільний і повний профілі також запускають вичерпні набори перевірок у реальному середовищі та E2E, а також частини Docker-перевірок шляху релізу; для бета-профілю їх можна ввімкнути через `run_release_soak=true`. Повторний запуск: `rerun_group=release-checks` або вужчий обробник перевірок релізу.
Пакетна перевірка Telegram	Завдання: `Run package Telegram E2E` Дочірній робочий процес: `NPM Telegram Beta E2E` Перевіряє: цільову E2E-перевірку Telegram для опублікованого пакета, коли задано `release_package_spec` або `npm_telegram_package_spec`. Повна перевірка кандидата натомість використовує канонічну E2E-перевірку Telegram у межах перевірки пакета. Повторний запуск: `rerun_group=npm-telegram` із `release_package_spec` або `npm_telegram_package_spec`.
Продуктивність продукту	Завдання: `Run product performance evidence` Дочірній робочий процес: `OpenClaw Performance` Перевіряє: запуск перевірки продуктивності профілю релізу (`profile=release`, `repeat=3`, `fail_on_regression=true`, `publish_reports=false`) для цільового SHA. Вивід Kova залишається в артефактах робочого процесу, а дочірній процес має підтвердити, що публікатор звіту було пропущено. Обов’язково й блокувально лише для `rerun_group=all` або `rerun_group=performance`; не обов’язково для вужчих груп повторного запуску. Повторний запуск: `rerun_group=performance`.
Парасольковий засіб перевірки	Завдання: `Verify full validation` Дочірній робочий процес: немає Перевіряє: повторно перевіряє записані результати дочірніх запусків і додає таблиці найповільніших завдань із дочірніх робочих процесів. Повторний запуск: після успішного повторного запуску невдалого дочірнього процесу повторно запустіть лише це завдання.

Парасольковий процес завжди запускає перевірку продуктивності продукту в режимі лише артефактів. OpenClaw Performance дозволяє публікацію звітів лише для запланованих запусків або ручного запуску, який явно задає publish_reports=true. Запобіжник режиму лише артефактів має успішно завершитися, підтвердивши, що завдання публікатора залишилося пропущеним. Нові та повторно використані докази записують controls.performanceReportPublication=artifact-only; засіб перевірки та селектор повторного використання відхиляють докази без відповідного нормалізованого підтвердження від дочірнього процесу перевірки продуктивності. Засіб перевірки завантажує канонічний маніфест як full-release-validation-<run-id>-<run-attempt>. Інструменти роботи з доказами перевіряють ідентифікатор артефакту, дайджест, запуск-виробник і спробу перед завантаженням саме цього ідентифікатора артефакту. Вони обмежують розмір завантажуваного ZIP, звіряють його байти з дайджестом REST sha256: і потоково читають єдиний дозволений запис маніфесту обмеженого розміру без розпакування архіву. Псевдонім зі стабільною назвою тимчасово залишається для старіших споживачів публікації. Засіб перевірки завжди надає перевагу артефакту з назвою, що містить номер спроби; як перехідний захід він приймає стабільну назву лише для маніфесту версії 2, створеного під час першої спроби. Він відхиляє цю застарілу назву для наступних спроб і маніфесту версії 3. Для ref=main із rerun_group=all, для посилань release/* і для альфа-посилань Tideclaw новіший запуск парасолькового процесу замінює старіший із тим самим посиланням і групою повторного запуску. Коли батьківський процес скасовано, його монітор скасовує всі вже запущені ним дочірні робочі процеси. Запуски перевірки тегів і закріплених SHA не скасовують один одного.

Етапи перевірок релізу

OpenClaw Release Checks — найбільший дочірній робочий процес. Він один раз визначає ціль і готує спільний артефакт release-package-under-test, коли він потрібен етапам роботи з пакетом або Docker.

Етап	Докладні відомості
Ціль випуску	Завдання: `Resolve target ref` Базовий робочий процес: немає Перевірки: вибране посилання, необов’язковий очікуваний SHA, профіль, група повторного запуску та фільтр цільового набору оперативних перевірок. Повторний запуск: `rerun_group=release-checks`.
Артефакт пакета	Завдання: `Prepare release package artifact` Базовий робочий процес: немає Перевірки: пакує або визначає один кандидатний tarball і завантажує `release-package-under-test` для подальших перевірок, пов’язаних із пакетом. Повторний запуск: відповідна група перевірок пакета, міжплатформних перевірок або оперативних/E2E-перевірок.
Димова перевірка встановлення	Завдання: `Run install smoke` Базовий робочий процес: `Install Smoke` Перевірки: повний шлях встановлення з повторним використанням димового образу кореневого Dockerfile, встановлення пакета QR, кореневі димові перевірки Docker і Docker-перевірки Gateway, Docker-перевірки інсталятора та димова перевірка постачальника образів із глобальним встановленням Bun. Повторний запуск: `rerun_group=install-smoke`.
Міжплатформні перевірки	Завдання: `cross_os_release_checks` Базовий робочий процес: `OpenClaw Cross-OS Release Checks (Reusable)` Перевірки: сценарії чистого встановлення й оновлення в Linux, Windows і macOS для вибраного постачальника та режиму з використанням кандидатного tarball і базового пакета. Повторний запуск: `rerun_group=cross-os`.
Репозиторні та оперативні E2E-перевірки	Завдання: `Run repo/live E2E validation` Базовий робочий процес: `OpenClaw Live And E2E Checks (Reusable)` Перевірки: репозиторні E2E-перевірки, оперативна перевірка кешу, потокове передавання OpenAI через WebSocket, сегменти нативних оперативних перевірок постачальників і Plugin, а також підтримувані Docker стенди оперативних перевірок моделі, серверної частини та Gateway, вибрані за `release_profile`. Запускається за умов: `run_release_soak=true`, `release_profile=full` або цільове `rerun_group=live-e2e`. Повторний запуск: `rerun_group=live-e2e`, необов’язково з `live_suite_filter`.
Шлях випуску Docker	Завдання: `Run Docker release-path validation` Базовий робочий процес: `OpenClaw Live And E2E Checks (Reusable)` Перевірки: частини Docker-перевірок шляху випуску зі спільним артефактом пакета. Запускається за умов: `run_release_soak=true`, `release_profile=full` або цільове `rerun_group=live-e2e`. Повторний запуск: `rerun_group=live-e2e`.
Приймальні перевірки пакета	Завдання: `Run package acceptance` Базовий робочий процес: `Package Acceptance` Перевірки: автономні тестові фікстури пакетів Plugin, оновлення Plugin, канонічна E2E-перевірка пакета Telegram з імітацією OpenAI та перевірки збереження працездатності після оновлення опублікованої версії з тим самим tarball. Блокувальні перевірки випуску використовують типову останню опубліковану базову версію; тривалі перевірки (`run_release_soak=true`) охоплюють останні 4 стабільні випуски npm і 3 закріплені історичні версії (`2026.4.23`, `2026.5.2`, `2026.4.15`) та виконуються з фікстурами оновлення для зареєстрованих проблем. Повторний запуск: `rerun_group=package`.
Картка оцінювання зрілості	Завдання: `Render maturity scorecard release docs` Базовий робочий процес: `maturity-scorecard.yml` Перевірки: формує рекомендаційну документацію картки оцінювання зрілості для цільового посилання. Запускається лише за передавання `run_maturity_scorecard=true`. Повторний запуск: `rerun_group=qa` з `run_maturity_scorecard=true`.
Паритет QA	Завдання: `Run QA Lab parity lane` і `Run QA Lab parity report` Базовий робочий процес: безпосередні завдання Перевірки: агентні набори перевірок паритету для кандидатної та базової версій, а потім звіт про паритет. Повторний запуск: `rerun_group=qa-parity` або `rerun_group=qa`.
Паритет середовищ виконання QA	Завдання: `Run QA Lab runtime parity lane` Базовий робочий процес: безпосереднє завдання Перевірки: агентний сценарій перевірки паритету пари середовищ виконання `openclaw`/`codex` (`pnpm openclaw qa suite --runtime-pair openclaw,codex`), що включає стандартний рівень і, за `run_release_soak=true`, рівень тривалих перевірок. Рекомендаційний статус: окремі збої не блокують засіб перевірки випуску. Повторний запуск: `rerun_group=qa-parity` або `rerun_group=qa`.
Покриття інструментів середовищ виконання QA	Завдання: `Enforce QA Lab runtime tool coverage` Базовий робочий процес: безпосереднє завдання Перевірки: динамічне розходження інструментів між `openclaw` і `codex` на стандартному рівні паритету середовищ виконання (`pnpm openclaw qa coverage --tools`) із використанням результату сценарію паритету середовищ виконання QA. Блокувальне: рекомендаційний статус цього завдання не можна перевизначити. Повторний запуск: `rerun_group=qa-parity` або `rerun_group=qa`.
Оперативна перевірка Matrix у QA	Завдання: `Run QA Lab live Matrix lane` Базовий робочий процес: безпосереднє завдання Перевірки: швидкий профіль оперативних QA-перевірок Matrix у середовищі `qa-live-shared`. Повторний запуск: `rerun_group=qa-live` або `rerun_group=qa`.
Оперативна перевірка Telegram у QA	Завдання: `Run QA Lab live Telegram lane` Базовий робочий процес: безпосереднє завдання Перевірки: оперативні QA-перевірки Telegram з орендою облікових даних Convex CI. Повторний запуск: `rerun_group=qa-live` або `rerun_group=qa`.
Засіб перевірки випуску	Завдання: `Verify release checks` Базовий робочий процес: немає Перевірки: обов’язкові завдання перевірки випуску для вибраної групи повторного запуску. Повторний запуск: повторіть запуск після успішного завершення цільових дочірніх завдань.

Частини Docker-перевірок шляху випуску

Етап Docker-перевірок шляху випуску запускає наведені нижче частини, коли live_suite_filter порожній:

Частина	Покриття
`core`	Основні сценарії димових Docker-перевірок шляху випуску.
`package-update-openai`	Поведінка встановлення й оновлення пакета OpenAI, встановлення Codex на вимогу, оперативні запуски Plugin Codex і виклики інструментів Chat Completions.
`package-update-anthropic`	Поведінка встановлення й оновлення пакета Anthropic.
`package-update-core`	Незалежна від постачальника поведінка пакета й оновлення.
`plugins-runtime-plugins`	Сценарії середовища виконання Plugin, що перевіряють поведінку Plugin.
`plugins-runtime-services`	Підтримувані службами й оперативні сценарії середовища виконання Plugin.
Від `plugins-runtime-install-a` до `plugins-runtime-install-h`	Пакети встановлення й виконання Plugin, розділені для паралельної перевірки випуску.
`openwebui`	Ізольована димова перевірка сумісності OpenWebUI на виділеному виконавці з великим диском, якщо її запитано.

Використовуйте цільове docker_lanes=<lane[,lane]> у повторно використовуваному робочому процесі оперативних/E2E-перевірок, коли збій стався лише в одному сценарії Docker. Артефакти випуску містять окремі для кожного сценарію команди повторного запуску з параметрами повторного використання артефакту пакета й образу, якщо вони доступні.

Профілі випуску

release_profile переважно керує широтою перевірок реального середовища та провайдерів у межах перевірок релізу. Він не вилучає звичайний повний CI, попередню перевірку релізу Plugin, димову перевірку встановлення, приймальне тестування пакета чи QA Lab. Стабільний і повний профілі завжди виконують вичерпне покриття E2E для репозиторію й реального середовища та тривалі перевірки шляху релізу в Docker. Бета-профіль може ввімкнути їх за допомогою run_release_soak=true. Приймальне тестування пакета забезпечує канонічний E2E Telegram для пакета для кожного повного кандидата, тому загальний процес не дублює цей модуль опитування реального середовища.

Профіль	Призначення	Включене покриття реального середовища та провайдерів
`beta`	Найшвидша критично важлива димова перевірка релізу.	Шлях реального середовища OpenAI/ядра, моделі реального середовища Docker для OpenAI, основний нативний gateway, нативний профіль gateway OpenAI, нативний Plugin OpenAI та gateway реального середовища Docker для OpenAI.
`stable`	Стандартний профіль затвердження релізу.	`beta` плюс димова перевірка Anthropic, Google, MiniMax, бекенд, нативний тестовий стенд реального середовища, бекенд CLI реального середовища Docker, прив’язка ACP у Docker, стенд Codex у Docker, оголошення субагентів у Docker і димовий шард OpenCode Go.
`full`	Широка рекомендаційна перевірка.	`stable` плюс рекомендаційні провайдери, шарди реального середовища плагінів і шарди реального середовища для медіа.

Доповнення лише для повного профілю

Ці набори пропускаються профілем stable і включаються профілем full:

Область	Покриття лише для повного профілю
Моделі реального середовища Docker	OpenCode Go, OpenRouter, xAI, Z.ai та Fireworks.
Gateway реального середовища Docker	Рекомендаційні провайдери, розділені на шарди DeepSeek/Fireworks, OpenCode Go/OpenRouter та xAI/Z.ai.
Профілі провайдерів нативного gateway	Повні шарди Anthropic Opus і Sonnet/Haiku, Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI та Z.ai.
Нативні шарди реального середовища плагінів	Плагіни A–K, L–N, інші O–Z, Moonshot і xAI.
Нативні шарди реального середовища для медіа	Аудіо, музика Google, музика MiniMax і групи відео A–D.

stable включає native-live-src-gateway-profiles-anthropic-smoke і native-live-src-gateway-profiles-opencode-go-smoke; full натомість використовує ширші шарди моделей Anthropic і OpenCode Go. Для цільових повторних запусків усе ще можна використовувати агреговані ідентифікатори native-live-src-gateway-profiles-anthropic або native-live-src-gateway-profiles-opencode-go.

Цільові повторні запуски

Використовуйте rerun_group, щоб не повторювати непов’язані середовища релізу:

Ідентифікатор	Обсяг
`all`	Усі етапи повної валідації релізу.
`ci`	Лише дочірній процес ручного повного CI.
`plugin-prerelease`	Лише дочірній процес попередньої перевірки релізу Plugin.
`release-checks`	Усі етапи перевірок релізу OpenClaw.
`install-smoke`	Димова перевірка встановлення та подальші перевірки релізу.
`cross-os`	Міжплатформні перевірки релізу.
`live-e2e`	E2E для репозиторію/реального середовища та валідація шляху релізу в Docker.
`package`	Приймальне тестування пакета.
`qa`	Узгодженість QA та смуги QA реального середовища.
`qa-parity`	Лише смуги та звіт узгодженості QA.
`qa-live`	Матриця QA реального середовища/Telegram плюс обмежені смуги Discord, WhatsApp і Slack, коли їх увімкнено.
`npm-telegram`	E2E Telegram для опублікованого пакета; потребує `release_package_spec` або `npm_telegram_package_spec`.
`performance`	Лише докази продуктивності продукту.

Використовуйте live_suite_filter з rerun_group=live-e2e, коли стався збій одного набору перевірок реального середовища. Допустимі ідентифікатори фільтрів визначено в багаторазовому робочому процесі реального середовища/E2E, зокрема docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker і live-codex-harness-docker. Ідентифікатор live-gateway-advisory-docker є агрегованим ідентифікатором повторного запуску для трьох шард провайдерів, тому він усе одно розгортає всі рекомендаційні завдання gateway Docker. Використовуйте cross_os_suite_filter з rerun_group=cross-os, коли стається збій однієї міжплатформної смуги. Фільтр приймає ідентифікатор ОС, ідентифікатор набору або пару ОС/набір, наприклад windows/packaged-upgrade, windows або packaged-fresh. Міжплатформні зведення містять тривалість кожної фази для смуг оновлення пакета, а довготривалі команди виводять рядки Heartbeat, щоб зависле оновлення було видно до завершення завдання через перевищення часу очікування. Збої перевірок релізу QA блокують звичайну валідацію релізу. Перевірка покриття інструментів середовища виконання QA (динамічне розходження інструментів між openclaw і codex у стандартному рівні) також блокує верифікатор перевірок релізу, хоча базова смуга узгодженості середовища виконання QA є рекомендаційною. Альфа-запуски Tideclaw усе ще можуть вважати рекомендаційними смуги перевірок релізу, що не стосуються безпеки пакета. З release_profile=beta набори провайдерів реального середовища Run repo/live E2E validation є рекомендаційними: розгортання моделей сторонніх постачальників змінюються незалежно від релізу, тому бета-профіль показує їхні збої як попередження, тоді як стабільний і повний профілі залишають їх блокувальними. Коли live_suite_filter явно запитує обмежену смугу QA реального середовища, наприклад Discord, WhatsApp або Slack, відповідну змінну репозиторію OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED має бути ввімкнено; інакше захоплення вхідних даних завершиться помилкою замість непомітного пропуску смуги. Повторно запустіть rerun_group=qa, qa-parity або qa-live, коли вам потрібні свіжі докази QA.

Докази, які слід зберігати

Зберігайте зведення Full Release Validation як індекс рівня релізу. Воно містить посилання на ідентифікатори дочірніх запусків і таблиці найповільніших завдань. У разі збоїв спочатку перевірте дочірній робочий процес, а потім повторно запустіть найменший відповідний ідентифікатор із наведених вище. Корисні артефакти:

release-package-under-test із OpenClaw Release Checks
Артефакти шляху релізу Docker у .artifacts/docker-tests/
package-under-test приймального тестування пакета й артефакти приймального тестування Docker
Артефакти міжплатформних перевірок релізу для кожної ОС і набору
Артефакти узгодженості QA, узгодженості середовища виконання, Matrix і Telegram

Файли робочих процесів

.github/workflows/full-release-validation.yml
.github/workflows/openclaw-release-checks.yml
.github/workflows/openclaw-live-and-e2e-checks-reusable.yml
.github/workflows/plugin-prerelease.yml
.github/workflows/install-smoke.yml
.github/workflows/install-smoke-reusable.yml
.github/workflows/openclaw-cross-os-release-checks-reusable.yml
.github/workflows/package-acceptance.yml
.github/workflows/openclaw-performance.yml
.github/workflows/npm-telegram-beta-e2e.yml

Release notes

Maturity

Release process

Testing and CI

Повна перевірка випуску

Етапи верхнього рівня

Етапи перевірок релізу

Частини Docker-перевірок шляху випуску

Профілі випуску

Доповнення лише для повного профілю

Цільові повторні запуски

Докази, які слід зберігати

Файли робочих процесів

​Етапи верхнього рівня

​Етапи перевірок релізу

​Частини Docker-перевірок шляху випуску

​Профілі випуску

​Доповнення лише для повного профілю

​Цільові повторні запуски

​Докази, які слід зберігати

​Файли робочих процесів

Етапи верхнього рівня

Етапи перевірок релізу

Частини Docker-перевірок шляху випуску

Профілі випуску

Доповнення лише для повного профілю

Цільові повторні запуски

Докази, які слід зберігати

Файли робочих процесів