Полная проверка релиза

Full Release Validation — комплексная проверка продукта перед выпуском. Большая часть работы выполняется в дочерних рабочих процессах, поэтому сбойную среду можно перезапустить без повторного запуска всего выпуска.

Зафиксируйте полностью готовый продуктовый коммит перед изменением журнала как Code SHA, затем выполните:

pnpm ci:full-release \  --sha <code-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 <trusted-main-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@<version>; запуски по 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 пропускает эту предварительную проверку.

Комплексный рабочий процесс всегда запускает проверку производительности продукта в режиме только артефактов. OpenClaw Performance разрешает публикацию отчёта только для запланированных запусков или ручного запуска, в котором явно задано publish_reports=true. Защитная проверка режима только артефактов должна успешно завершиться, подтвердив, что задание публикации осталось пропущенным. Как новые, так и повторно используемые свидетельства записывают controls.performanceReportPublication=artifact-only; средство проверки и селектор повторного использования отклоняют свидетельства без соответствующего нормализованного подтверждения дочерней проверки производительности.

Средство проверки загружает канонический манифест как full-release-validation-<run-id>-<run-attempt>. Инструменты обработки свидетельств проверяют идентификатор артефакта, контрольную сумму, создавший его запуск и попытку, прежде чем загрузить артефакт именно с этим идентификатором. Они ограничивают размер загружаемого ZIP-файла, сверяют его байты с контрольной суммой sha256: из REST и потоково считывают единственную разрешённую ограниченную запись манифеста, не извлекая архив. Псевдоним со стабильным именем временно сохраняется для прежних потребителей публикации. Средство проверки всегда предпочитает артефакт с указанием попытки; на переходный период оно принимает стабильное имя только для манифеста v2, созданного с первой попытки. Для последующих попыток и манифеста v3 это устаревшее имя отклоняется.

Для ref=main с rerun_group=all, для ссылок release/* и для альфа-ссылок Tideclaw более новый запуск комплексного рабочего процесса заменяет старый запуск с той же ссылкой и группой повторного запуска. При отмене родительского процесса его монитор отменяет все уже запущенные им дочерние рабочие процессы. Запуски проверок по тегам и закреплённым SHA не отменяют друг друга.

Этапы проверок выпуска

OpenClaw Release Checks — крупнейший дочерний рабочий процесс. Он однократно разрешает целевую ссылку и подготавливает общий артефакт release-package-under-test, когда он необходим этапам, работающим с пакетами или Docker.

Блоки пути выпуска Docker

Этап пути выпуска Docker выполняет следующие блоки, когда live_suite_filter пуст:

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

Профили выпуска

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

Дополнения только для полного профиля

Эти наборы тестов пропускаются в stable и включаются в full:

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, чтобы не запускать повторно несвязанные среды выпуска:

Используйте 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