--- read_when: - Запуск или повторный запуск полной проверки релиза - Сравнение профилей проверки стабильного и полного выпуска - Отладка сбоев на этапе проверки релиза summary: Этапы полной проверки релиза, дочерние рабочие процессы, профили релиза, механизмы повторного запуска и подтверждающие материалы title: Полная проверка релиза x-i18n: generated_at: "2026-07-13T20:15:43Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: f4dad526111a514392a6a0108e88ed276461155ac6768444458eb44ad8c0ee35 source_path: reference/full-release-validation.md workflow: 16 --- `Full Release Validation` — комплексная проверка продукта перед выпуском. Большая часть работы выполняется в дочерних рабочих процессах, поэтому сбойную среду можно перезапустить без повторного запуска всего выпуска. Зафиксируйте полностью готовый продуктовый коммит перед изменением журнала как **Code SHA**, затем выполните: ```bash pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH ``` `provider` также принимает `anthropic` или `minimax` для кроссплатформенного первоначального настроечного запуска и сквозного цикла агента. Вспомогательная команда определяет профиль `beta` по альфа- или бета- версиям пакетов, а в остальных случаях — `stable`. Передавайте альтернативные входные параметры рабочего процесса через `-f key=value`; используйте `-f release_profile=full` только для широкой проверки рекомендаций. Вспомогательная команда создаёт временную ссылку `release-ci/*`, закреплённую за одним доверенным SHA рабочего процесса `origin/main`, передаёт целевой SHA только как кандидат `ref` и удаляет временную ссылку после проверки. Каждый запущенный дочерний процесс должен сообщить тот же SHA рабочего процесса. Передайте `-f reuse_evidence=false`, чтобы принудительно запустить проверку заново, или `--workflow-sha `, чтобы выбрать более старый коммит рабочего процесса, всё ещё доступный из текущего `origin/main`. Сам рабочий процесс никогда не создаёт и не обновляет ссылки репозитория. Когда Code SHA успешно пройдёт проверки, создайте и зафиксируйте коммитом только `CHANGELOG.md`. Этот новый коммит станет **Release SHA**. Запустите ту же вспомогательную команду для Release SHA. Продуктовые свидетельства повторно используются только тогда, когда GitHub подтверждает, что Release SHA является потомком Code SHA, а полный набор изменённых путей в точности равен `CHANGELOG.md`; предварительная проверка npm и приёмочные проверки пакета и установки всё равно выполняются для Release SHA. `release_profile=stable` и `release_profile=full` всегда запускают исчерпывающую длительную проверку в реальной среде и Docker. Передайте `run_release_soak=true`, чтобы включить те же этапы длительной проверки с профилем `beta`. Стабильная публикация отклоняет манифест проверки, в котором отсутствуют эта длительная проверка и блокирующие свидетельства производительности продукта. Package Acceptance обычно собирает кандидатный tarball из разрешённого `ref`, включая запуски для полного SHA, инициированные с `pnpm ci:full-release`. После публикации бета-версии передайте `release_package_spec=openclaw@YYYY.M.PATCH-beta.N`, чтобы повторно использовать опубликованный пакет npm в проверках выпуска, Package Acceptance, кроссплатформенных проверках, Docker-проверках пути выпуска и пакетной проверке Telegram. Используйте `package_acceptance_package_spec` только тогда, когда Package Acceptance должна намеренно проверить другой пакет. Этап проверки пакета плагина Codex в реальной среде следует той же модели: опубликованные значения `release_package_spec` определяют `codex_plugin_spec=npm:@openclaw/codex@`; запуски по SHA или артефакту упаковывают `extensions/codex` из выбранной ссылки; операторы могут напрямую задать `codex_plugin_spec` для источников плагина `npm:`, `npm-pack:` или `git:`. Этап предоставляет явное разрешение на установку Codex CLI, необходимое этому плагину, затем выполняет предварительную проверку Codex CLI и циклы агента OpenAI в том же сеансе. ## Этапы верхнего уровня Для `rerun_group=all` сначала выполняется задание `Check for reusable validation evidence`. Оно ищет последнюю предыдущую успешно завершённую полную проверку с тем же профилем выпуска, фактической настройкой длительной проверки и входными параметрами проверки. Повторные запуски для той же цели используют `exact-target-full-validation-v1`. Для потомка, полный набор изменений которого в точности равен `CHANGELOG.md`, используется `changelog-only-release-v1`; все продуктовые этапы пропускаются, а средство проверки независимо повторно проверяет сравнение коммитов GitHub, неизменяемый родительский артефакт, дочерние запуски и журналы запуска. Любое другое изменение цели требует новой проверки Code SHA. Передайте `reuse_evidence=false`, чтобы принудительно выполнить новую полную проверку. Повторное использование свидетельств выполняется только из `main` или канонической ссылки `release-ci/*`, закреплённой за SHA, чей коммит рабочего процесса остаётся в доверенной линии `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, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, совместимость с Node 22, `check-*`, `check-additional-*`, дымовые проверки собранных артефактов, проверки документации, Python Skills, Windows, macOS, интернационализацию Control UI и Android через комплексный рабочий процесс.
**Повторный запуск:** `rerun_group=ci`. | | Предвыпускная проверка плагинов | **Задание:** `Run plugin prerelease validation`
**Дочерний рабочий процесс:** `Plugin Prerelease`
**Подтверждает:** статические проверки плагинов только для выпуска, агентное покрытие плагинов, полные пакетные сегменты плагинов, предвыпускные Docker-этапы плагинов и неблокирующий артефакт `plugin-inspector-advisory` для анализа совместимости.
**Повторный запуск:** `rerun_group=plugin-prerelease`. | | Проверки выпуска | **Задание:** `Run release/live/Docker/QA validation`
**Дочерний рабочий процесс:** `OpenClaw Release Checks`
**Подтверждает:** дымовую проверку установки, кроссплатформенные проверки пакета, Package Acceptance, соответствие 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 в Package Acceptance.
**Повторный запуск:** `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--`. Инструменты обработки свидетельств проверяют идентификатор артефакта, контрольную сумму, создавший его запуск и попытку, прежде чем загрузить артефакт именно с этим идентификатором. Они ограничивают размер загружаемого ZIP-файла, сверяют его байты с контрольной суммой `sha256:` из REST и потоково считывают единственную разрешённую ограниченную запись манифеста, не извлекая архив. Псевдоним со стабильным именем временно сохраняется для прежних потребителей публикации. Средство проверки всегда предпочитает артефакт с указанием попытки; на переходный период оно принимает стабильное имя только для манифеста v2, созданного с первой попытки. Для последующих попыток и манифеста v3 это устаревшее имя отклоняется. Для `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, дымовыми тестами корневого компонента и Gateway в Docker, тестами установщика в 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, нативные сегменты поставщиков и плагинов с реальными сервисами, а также работающие в 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`
**Тесты:** автономные фикстуры пакетов плагинов, обновление плагина, канонический 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`. | | QA Matrix с реальным сервисом | **Задание:** `Run QA Lab live Matrix lane`
**Базовый рабочий процесс:** непосредственное задание
**Тесты:** быстрый профиль QA Matrix с реальным сервисом в среде `qa-live-shared`.
**Повторный запуск:** `rerun_group=qa-live` или `rerun_group=qa`. | | QA Telegram с реальным сервисом | **Задание:** `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 по требованию, обращения к плагину Codex с реальным сервисом и вызовы инструментов Chat Completions. | | `package-update-anthropic` | Установка и обновление пакета Anthropic. | | `package-update-core` | Независимое от поставщика поведение пакета и обновления. | | `plugins-runtime-plugins` | Сценарии среды выполнения плагинов, проверяющие поведение плагинов. | | `plugins-runtime-services` | Сценарии сред выполнения плагинов с сервисной поддержкой и реальными сервисами. | | С `plugins-runtime-install-a` по `plugins-runtime-install-h` | Пакеты установки и выполнения плагинов, разделённые для параллельной проверки выпуска. | | `openwebui` | Изолированный дымовой тест совместимости с OpenWebUI на выделенном исполнителе с большим диском, если он запрошен. | Используйте целевой `docker_lanes=` в повторно используемом рабочем процессе с реальными сервисами/E2E, если завершился сбоем только один сценарий Docker. Артефакты выпуска содержат команды повторного запуска для каждого сценария с параметрами повторного использования артефакта пакета и образа, когда они доступны. ## Профили выпуска `release_profile` главным образом управляет широтой охвата реальных сервисов и поставщиков в проверках выпуска. Он не исключает обычные полные CI, предварительную проверку выпуска плагина, дымовой тест установки, приёмку пакета или QA Lab. Стабильный и полный профили всегда выполняют исчерпывающие E2E репозитория/реальных сервисов и продолжительные проверки пути выпуска Docker. Бета-профиль может включить их с помощью `run_release_soak=true`. Приёмка пакета предоставляет канонический E2E пакета Telegram для каждого полного кандидата, поэтому общий рабочий процесс не дублирует этот опрос реального сервиса. | Профиль | Предназначение | Включённое покрытие тестами с реальными сервисами/провайдерами | | -------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `beta` | Самая быстрая критически важная для выпуска дымовая проверка. | Основной путь OpenAI с реальными сервисами, модели Docker с реальными сервисами для OpenAI, основная часть нативного Gateway, нативный профиль Gateway для OpenAI, нативный плагин OpenAI и Gateway OpenAI в Docker с реальными сервисами. | | `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` | Только дочерний процесс предварительного выпуска плагинов. | | `release-checks` | Все этапы проверок выпуска OpenClaw. | | `install-smoke` | От дымовой проверки установки до проверок выпуска. | | `cross-os` | Кроссплатформенные проверки выпуска. | | `live-e2e` | Сквозные тесты репозитория/реальных сервисов и проверка пути выпуска в Docker. | | `package` | Приёмочное тестирование пакета. | | `qa` | Проверка эквивалентности QA и каналы QA с реальными сервисами. | | `qa-parity` | Только каналы проверки эквивалентности QA и отчёт. | | `qa-live` | Matrix/Telegram с реальными сервисами для QA, а также управляемые каналы Discord, WhatsApp и Slack, когда они включены. | | `npm-telegram` | Сквозной тест Telegram для опубликованного пакета; требуется `release_package_spec` или `npm_telegram_package_spec`. | | `performance` | Только свидетельства производительности продукта. | Используйте `live_suite_filter` с `rerun_group=live-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` как индекс уровня выпуска. Она содержит ссылки на идентификаторы дочерних запусков и таблицы самых медленных заданий. При сбоях сначала изучите дочерний рабочий процесс, затем повторно запустите наименьший подходящий дескриптор из перечисленных выше. Зафиксируйте Code SHA и Release SHA, политику повторного использования и набор изменённых путей, родительский запуск с успешным Code SHA и облегчённый родительский запуск с Release SHA. Полезные артефакты: - `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`