Конвейер CI

OpenClaw CI запускается при отправке изменений в main (пути Markdown и docs/** игнорируются триггером), для запросов на включение изменений, не являющихся черновиками (изменения только в CHANGELOG игнорируются), а также при ручном запуске. Канонические отправки изменений в main сначала проходят через 90-секундное окно допуска на размещённом исполнителе; группа параллелизма CI отменяет этот ожидающий запуск при поступлении более нового коммита, поэтому последовательные слияния не регистрируют каждый раз полную матрицу Blacksmith. Запросы на включение изменений и ручные запуски пропускают ожидание. Затем задание preflight классифицирует изменения и отключает ресурсоёмкие направления, если изменены только несвязанные области. Ручные запуски workflow_dispatch намеренно обходят интеллектуальное ограничение области и разворачивают полный граф для кандидатов на выпуск и широкой проверки. Направления Android остаются доступными по явному запросу через include_android (или входной параметр release_gate). Проверка плагинов, выполняемая только для выпусков, находится в отдельном рабочем процессе Plugin Prerelease и запускается только из Full Release Validation либо при явном ручном запуске.

Обзор конвейера

Автономные рабочие процессы Periphery обеспечивают отсутствие результатов обнаружения неиспользуемого кода в приложениях iOS и macOS. Общий рабочий процесс OpenClawKit параллельно сканирует оба потребителя и сообщает о декларации только тогда, когда Periphery выдаёт один и тот же Swift USR в обеих сборках. Контракт созданной схемы OpenClawProtocol/GatewayModels.swift сохраняется как код, принадлежащий генератору, а не считается неиспользуемым кодом конкретного приложения.

Порядок быстрого отказа

1. runner-admission ожидает только для канонических отправок изменений в main; более новая отправка отменяет запуск до регистрации в Blacksmith.
2. preflight определяет, какие направления вообще существуют. Логика docs-scope и changed-scope представляет собой шаги внутри этого задания, а не отдельные задания.
3. security-fast, check-*, check-additional-*, check-docs и skills-python быстро завершаются с ошибкой, не ожидая более ресурсоёмких заданий матрицы артефактов и платформ.
4. build-artifacts и рекомендательная проверка control-ui-i18n выполняются параллельно с быстрыми направлениями Linux. Расхождение созданных локализаций остаётся видимым, пока автономный рабочий процесс обновления исправляет его в фоновом режиме.
5. После этого разворачиваются более ресурсоёмкие направления платформ и сред выполнения: checks-fast-core, checks-fast-contracts-plugins-*, checks-fast-contracts-channels-*, checks-node-*, checks-windows, macos-node, macos-swift, ios-build и android.

GitHub может помечать вытесненные задания как cancelled, когда более новая отправка поступает в тот же запрос на включение изменений или ссылку main. Считайте это шумом CI, если только самый новый запуск для той же ссылки также не завершается с ошибкой. Задания матрицы используют fail-fast: false, а build-artifacts сообщает непосредственно об ошибках встроенных каналов, границ поддержки ядра и наблюдения за Gateway вместо постановки в очередь небольших заданий проверки. Ключ параллелизма автоматического CI версионируется (CI-v7-*), чтобы зависший на стороне GitHub процесс в старой группе очереди не мог бесконечно блокировать новые запуски основной ветви. Ручные запуски полного набора используют CI-manual-v1-* и не отменяют выполняющиеся запуски. Защитная проверка памяти при запуске списка плагинов сохраняет предел 350 MiB в самостоятельно размещённой среде Blacksmith Linux и допускает 425 MiB в размещённой GitHub среде Linux, где базовый уровень RSS выше для того же собранного CLI.

Используйте pnpm ci:timings, pnpm ci:timings:recent или node scripts/ci-run-timings.mjs <run-id>, чтобы получить сводку общего времени, времени в очереди, самых медленных заданий, ошибок и барьера развёртывания pnpm-store-warmup из GitHub Actions. Задание ci-timings-summary внутри рабочего процесса существует в ci.yml, но сейчас отключено (if: false); вместо него запускайте вспомогательное средство измерения времени локально. Для времени сборки проверьте шаг Build dist задания build-artifacts: pnpm build:ci-artifacts выводит [build-all] phase timings: и включает ui:build; задание также отправляет артефакт startup-memory.

Контекст запроса на включение изменений и свидетельства

Внешние PR от участников запускают проверку контекста и доказательств PR из .github/workflows/real-behavior-proof.yml. Рабочий процесс извлекает доверенную ревизию рабочего процесса (github.workflow_sha) и оценивает только описание PR; код из ветки участника не выполняется.

Проверка применяется к авторам PR, которые не являются владельцами репозитория, его участниками, соавторами или ботами. Она проходит, когда описание PR содержит написанные автором разделы What Problem This Solves и Evidence. Доказательством может служить целевой тест, результат CI, снимок экрана, запись, вывод терминала, наблюдение в реальной среде, отредактированный журнал или ссылка на артефакт. Описание поясняет намерение и содержит полезные результаты проверки; рецензенты изучают код, тесты и CI, чтобы оценить корректность.

Если проверка завершается неудачно, обновите описание PR вместо отправки ещё одного коммита с кодом.

Область действия и маршрутизация

Логика областей действия находится в scripts/ci-changed-scope.mjs и покрыта модульными тестами в src/scripts/ci-changed-scope.test.ts. Ручной запуск пропускает определение изменённых областей и заставляет манифест предварительной проверки считать, что изменилась каждая контролируемая область.

Отдельные рабочие процессы Periphery для iOS и macOS применяют политику нулевого количества обнаружений мёртвого кода. Каждый из них запускается только тогда, когда пул-реквест, не являющийся черновиком, затрагивает соответствующую область сканирования нативного кода, либо при ручном запуске.

• Изменения рабочих процессов CI проверяют граф Node CI, линтинг рабочих процессов и задание Windows (ci.yml выполняет его), но сами по себе не принуждают к сборке нативного кода iOS, Android или macOS; эти платформенные задания по-прежнему ограничены изменениями исходного кода соответствующей платформы.
• Проверка корректности рабочих процессов запускает actionlint, zizmor для всех YAML-файлов рабочих процессов, защиту интерполяции составных действий и защиту от маркеров конфликтов. Ограниченное PR задание security-fast также запускает zizmor для изменённых файлов рабочих процессов, чтобы проблемы безопасности рабочих процессов приводили к раннему сбою в основном графе CI.
• Документация при отправке изменений в main проверяется автономным рабочим процессом Docs с тем же зеркалом документации ClawHub, которое использует CI, поэтому отправки, содержащие одновременно изменения кода и документации, не ставят дополнительно в очередь сегмент CI check-docs. Для пул-реквестов и ручных запусков CI по-прежнему выполняется check-docs из CI, если документация изменилась.
• TUI PTY запускается в сегменте Linux Node checks-node-core-runtime-tui-pty при изменениях TUI. Сегмент запускает test/vitest/vitest.tui-pty.config.ts с OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1, поэтому он охватывает как детерминированное задание с фикстурой TuiBackend, так и более медленную дымовую проверку tui --local, которая имитирует только внешний эндпоинт модели.
• Изменения только маршрутизации CI, небольшой набор фикстур тестов ядра, непосредственно запускаемых быстрым заданием, и узкие изменения вспомогательных средств контрактов плагинов используют быстрый путь манифеста только для Node: preflight, security-fast и только быстрые задания, затронутые изменением, — одно задание маршрутизации CI checks-fast-core, два сегмента контрактов плагинов либо оба варианта. Этот путь пропускает артефакты сборки, совместимость с Node 22, контракты каналов, полные сегменты ядра, сегменты встроенных плагинов и дополнительные матрицы защитных проверок.
• Проверки Node для Windows ограничены специфичными для Windows обёртками процессов и путей, вспомогательными средствами запуска npm/pnpm/UI, конфигурацией менеджера пакетов и поверхностями рабочего процесса CI, выполняющими это задание; несвязанные изменения исходного кода, плагинов, дымовых проверок установки и только тестов остаются в заданиях Linux Node.

Самые медленные семейства тестов Node разделены или сбалансированы, чтобы каждое задание оставалось небольшим без избыточного резервирования исполнителей:

• Контракты плагинов и контракты каналов запускаются в виде двух взвешенных сегментов с исполнителями Blacksmith и стандартным резервным исполнителем GitHub.
• Быстрое и вспомогательное задания модульных тестов ядра запускаются отдельно; инфраструктура среды выполнения ядра разделена на процессы, общие компоненты, хуки, секреты и три доменных сегмента Cron.
• Автоответ запускается сбалансированными воркерами, а поддерево ответов разделено на сегменты запуска агента, команд, диспетчеризации, сеанса и маршрутизации состояния.
• Конфигурации агентных Gateway/сервера (плоскости управления) разделены на задания чата, аутентификации, модели, HTTP/плагинов, среды выполнения и запуска вместо ожидания собранных артефактов.
• Обычный CI объединяет только изолированные сегменты инфраструктуры с шаблонами включения в детерминированные пакеты не более чем по 64 тестовых файла, сокращая матрицу Node без объединения неизолированных наборов команд/Cron, ядра агентов с состоянием или Gateway/сервера. Тяжёлые фиксированные наборы по-прежнему используют 8 виртуальных ЦП, а объединённые задания и задания с меньшим весом — 4 виртуальных ЦП.
• Пул-реквесты в каноническом репозитории используют компактный план допуска: те же группы для каждой конфигурации запускаются в изолированных подпроцессах, в настоящее время это 14 заданий тестов Node вместо полной матрицы из 74 заданий. Пакеты целых конфигураций сохраняют тайм-аут 120 минут, а последовательная конфигурация инструментов распределяется по трём группам только для PR; отправки в main, ручные запуски и проверки релиза сохраняют полную матрицу.
• Полная матрица Node сначала допускает стабильно медленные сегменты последовательных инструментов и команд автоответа. Это сохраняет ограничение в 28 заданий и не позволяет коротким группам, отсортированным по алфавиту, вытеснять работу критического пути в следующую волну.
• Широкие тесты браузера, QA, мультимедиа и прочих плагинов используют собственные конфигурации Vitest вместо общей конфигурации для всех плагинов. Сегменты с шаблонами включения записывают данные времени с именем сегмента CI, чтобы .artifacts/vitest-shard-timings.json мог отличать целую конфигурацию от отфильтрованного сегмента.
• check-additional-* распределяет дополнительный список защитных проверок границ (scripts/run-additional-boundary-checks.mjs) между одним сегментом с высокой нагрузкой на промпты (check-additional-boundaries-a, включающим проверку расхождения снимка промпта Codex) и одним объединённым сегментом для остальных полос (check-additional-boundaries-bcd); каждый из них параллельно запускает независимые защитные проверки и выводит время каждой проверки. Компиляция и канареечные проверки границ пакетов остаются вместе, а архитектура топологии среды выполнения запускается отдельно от покрытия наблюдения Gateway, встроенного в build-artifacts.
• Наблюдение Gateway, тесты каналов и сегмент вспомогательных границ ядра параллельно запускаются внутри build-artifacts после того, как dist/ и dist-runtime/ уже собраны.

После допуска канонический Linux CI разрешает одновременно выполнять до 28 заданий тестов Node и 12 более компактных быстрых заданий и проверок; для Windows и Android предел остаётся равным двум, поскольку их пулы исполнителей меньше. Компактные пакеты целых конфигураций запускаются с пакетным тайм-аутом 120 минут, а группы с шаблонами включения используют тот же ограниченный бюджет заданий.

Android CI запускает как testPlayDebugUnitTest, так и testThirdPartyDebugUnitTest, а затем собирает отладочный APK для Play. У варианта стороннего распространения нет отдельного набора исходного кода или манифеста; его задание модульных тестов всё равно компилирует вариант с флагами BuildConfig для SMS и журнала вызовов, избегая при этом дублирующего задания упаковки отладочного APK при каждой отправке изменений, относящихся к Android.

Сегмент check-dependencies запускает производственные проверки Knip для зависимостей, неиспользуемых файлов и неиспользуемых экспортов. Защита от неиспользуемых файлов завершается неудачно, если PR добавляет новый непроверенный неиспользуемый файл или оставляет устаревшую запись в списке разрешений, при этом сохраняя намеренно динамические поверхности плагинов, сгенерированного кода, сборки, живых тестов и связующих компонентов пакетов, которые Knip не может разрешить статически. Защита от неиспользуемых экспортов исключает файлы поддержки тестов, а затем завершается неудачно при новых обнаружениях или устаревших обязательных записях базового списка; после удаления мёртвых экспортов повторно создайте базовый список, допускающий только сокращение, с помощью pnpm deadcode:exports:update. Исторические цели запускают защиту экспортов, если она у них предусмотрена, а в противном случае сохраняют прежнюю резервную проверку мёртвого кода.

Перенаправление активности ClawSweeper

.github/workflows/clawsweeper-dispatch.yml — это мост на стороне целевого репозитория, передающий активность репозитория OpenClaw в ClawSweeper. Он не извлекает и не выполняет недоверенный код пул-реквестов. Рабочий процесс создаёт токен GitHub App из CLAWSWEEPER_APP_PRIVATE_KEY, а затем отправляет компактные полезные нагрузки repository_dispatch в openclaw/clawsweeper.

Рабочий процесс включает четыре задания:

• clawsweeper_item для запросов на проверку конкретных задач и пул-реквестов;
• clawsweeper_comment для явных команд ClawSweeper в комментариях к задачам;
• clawsweeper_commit_review для запросов на проверку отдельных коммитов при отправке изменений в main;
• github_activity для общей активности GitHub, которую может анализировать агент ClawSweeper.

Задание github_activity перенаправляет только нормализованные метаданные: тип события, действие, инициатора, репозиторий, номер элемента, URL, заголовок, состояние и короткие фрагменты комментариев или рецензий при их наличии. Оно намеренно не перенаправляет полное тело Webhook. Принимающий рабочий процесс в openclaw/clawsweeper — .github/workflows/github-activity.yml, который отправляет нормализованное событие в хук OpenClaw Gateway для агента ClawSweeper.

Общая активность предназначена для наблюдения, а не для доставки по умолчанию. Агент ClawSweeper получает целевой адрес Discord в своём промпте и должен отправлять сообщения в #clawsweeper только тогда, когда событие неожиданно, требует действий, несёт риск или полезно для эксплуатации. Обычные открытия и изменения, активность ботов, дублирующий шум Webhook и стандартный поток рецензий должны приводить к NO_REPLY.

На всём этом пути считайте заголовки, комментарии, описания, тексты рецензий, имена веток и сообщения коммитов GitHub недоверенными данными. Они служат входными данными для обобщения и сортировки, а не инструкциями для рабочего процесса или среды выполнения агента.

Ручные запуски

Ручные запуски CI используют тот же граф заданий, что и обычный CI, но принудительно включают все ограниченные областью задания, кроме Android: сегменты Linux Node, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, совместимость с Node 22, check-*, check-additional-*, дымовые проверки собранных артефактов, проверки документации, Python-навыки, Windows, macOS, сборку iOS и интернационализацию Control UI. Соответствие локалей Control UI имеет рекомендательный характер при автоматических запусках PR и main, поскольку автономный рабочий процесс обновления исправляет расхождения сгенерированных данных в фоновом режиме; при ручном запуске CI эта проверка блокирующая и, следовательно, блокирует полную проверку релиза. Автономные ручные запуски CI запускают Android только с include_android=true (параметр release_gate также принудительно включает Android); общий процесс полной проверки релиза включает Android, передавая include_android=true. Статические проверки плагинов перед релизом, предназначенный только для релиза сегмент agentic-plugins, полная пакетная проверка расширений и Docker-задания предварительной проверки плагинов исключены из CI. Набор предварительных Docker-проверок запускается только тогда, когда Full Release Validation запускает отдельный рабочий процесс Plugin Prerelease с включённой проверкой релиза.

Ручные запуски используют уникальную группу параллелизма, поэтому полный набор проверок кандидата на выпуск не отменяется другим запуском при отправке изменений или для PR в той же ссылке Git. Необязательный параметр target_ref позволяет доверенному вызывающему запустить этот граф для ветки, тега или полного SHA коммита, используя файл рабочего процесса из выбранной ссылки запуска. Необязательный параметр loc_base_ref задаёт точный SHA для сравнения при автономных ручных запусках. Параметр release_gate — резервный механизм сопровождающего с точным SHA для CI пул-реквестов, остановленного из-за нехватки ресурсов: он требует, чтобы target_ref был полным SHA коммита, совпадающим с вершиной запускаемой ветки, а pr_number указывал открытый пул-реквест. Рабочий процесс проверяет текущую вершину и базовую ветку этого PR, ожидает завершения вычисления возможности слияния в GitHub, фиксирует сообщённый тестовый коммит слияния, получает синтетическую ссылку GitHub на слияние пул-реквеста, проверяет её SHA и обоих родителей, а затем извлекает это дерево перед установкой зависимостей и запуском ограничителя LOC TypeScript для изменённых файлов. Это соответствует объединённому дереву и реализации политики автоматического CI для PR. Ревизии рабочих процессов, принадлежащие целевой стороне и не содержащие pr_number, не могут предоставить эквивалентные доказательства для дерева слияния; обновите вершину PR до текущего рабочего процесса и повторно запустите проверку точной вершины вместо использования резервного механизма.

gh workflow run ci.yml --ref release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=truegh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

Ежемесячный путь расширенной стабильной публикации только в npm является исключением: запустите вручную как предварительную проверку OpenClaw NPM Release и Full Release Validation из точной ветки extended-stable/YYYY.M.33, сохраните идентификаторы их запусков и передайте оба идентификатора в запуск прямой публикации в npm. Команды, точные требования к идентичности, обратную проверку реестра и процедуру исправления селектора см. в разделе Ежемесячная расширенная стабильная публикация только в npm. Этот путь не запускает публикацию плагинов, macOS, Windows, GitHub Release, приватного тега дистрибутива или других платформ.

Среды выполнения

Бюджет регистрации сред выполнения

Текущий сегмент регистрации сред выполнения GitHub для OpenClaw предусматривает 10 000 регистраций самостоятельно размещённых сред выполнения за 5 минут в ghx api rate_limit. Перед каждым этапом настройки повторно проверяйте actions_runner_registration, поскольку GitHub может изменить этот сегмент. Ограничение совместно используется всеми регистрациями сред выполнения Blacksmith в организации openclaw, поэтому добавление ещё одной установки Blacksmith не создаёт новый сегмент.

Считайте метки Blacksmith дефицитным ресурсом для управления всплесками. Задания, которые только маршрутизируют, уведомляют, формируют сводки, выбирают сегменты или выполняют короткие проверки CodeQL, должны оставаться в средах выполнения, размещённых GitHub, если для них не подтверждена измерениями потребность именно в Blacksmith. Для любой новой матрицы Blacksmith, увеличенного max-parallel или часто запускаемого рабочего процесса необходимо указать максимальное число регистраций в худшем случае и удерживать целевой показатель на уровне организации ниже примерно 60% фактического сегмента. При текущем сегменте в 10 000 регистраций это означает рабочий целевой показатель в 6 000 регистраций с резервом для параллельных репозиториев, повторных попыток и перекрывающихся всплесков.

CI канонического репозитория сохраняет Blacksmith в качестве пути среды выполнения по умолчанию для обычных запусков при отправке изменений и запросах на слияние. workflow_dispatch и запуски в неканонических репозиториях используют среды выполнения, размещённые GitHub, однако обычные канонические запуски сейчас не проверяют состояние очереди Blacksmith и не переключаются автоматически на метки сред выполнения, размещённых GitHub, когда Blacksmith недоступен.

Локальные эквиваленты

pnpm changed:lanes                            # проверить локальный классификатор изменённых путей для origin/main...HEADpnpm check:changed                            # интеллектуальный локальный шлюз проверок: изменённые форматирование, проверка типов, линтинг и защитные проверки по граничным путямpnpm check                                    # быстрый локальный шлюз: prod tsgo + сегментированный линтинг + параллельные быстрые защитные проверкиpnpm check:test-typespnpm check:timed                              # тот же шлюз с замерами времени каждого этапаpnpm build:strict-smokepnpm check:architecturepnpm test:gateway:watch-regressionOPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.tspnpm test                                     # тесты vitestpnpm test:changed                             # недорогие интеллектуально выбранные цели Vitest для измененийpnpm test:ui                                  # модульный/браузерный набор Control UIpnpm ui:i18n:check                            # соответствие сгенерированных локалей Control UI (шлюз выпуска)pnpm test:channelspnpm test:contracts:channelspnpm check:docs                               # форматирование документации + линтинг + неработающие ссылкиpnpm build                                    # собрать dist, когда важны проверки артефактов/дымовые проверки CIpnpm ios:build                                # сгенерировать и собрать проект приложения iOSpnpm ci:timings                               # свести данные последнего запуска CI при отправке в origin/mainpnpm ci:timings:recent                        # сравнить недавние успешные запуски CI для mainnode scripts/ci-run-timings.mjs <run-id>      # свести общее время, время ожидания в очереди и самые медленные заданияnode scripts/ci-run-timings.mjs --latest-main # игнорировать шум от задач/комментариев и выбрать CI отправки в origin/mainnode scripts/ci-run-timings.mjs --recent 10   # сравнить недавние успешные запуски CI для mainpnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.jsonpnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.jsonpnpm test:startup:memorypnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.jsonpnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

Производительность OpenClaw

OpenClaw Performance — рабочий процесс производительности продукта и среды выполнения. Он запускается ежедневно в main, также его можно запустить вручную:

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=truegh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

При ручном запуске обычно измеряется производительность ссылки рабочего процесса. Задайте target_ref, чтобы измерить производительность тега выпуска или другой ветки с текущей реализацией рабочего процесса. Пути опубликованных отчётов и указатели на последние версии привязаны к проверяемой ссылке, а каждый index.md фиксирует проверяемую ссылку/SHA, ссылку/SHA рабочего процесса, ссылку Kova, профиль, режим аутентификации пути, модель, число повторов и фильтры сценариев.

Рабочий процесс устанавливает OCM из закреплённого выпуска и Kova из openclaw/Kova по закреплённому входному значению kova_ref, а затем выполняет три пути:

• mock-provider: диагностические сценарии Kova для локально собранной среды выполнения с детерминированной фиктивной аутентификацией, совместимой с OpenAI.
• mock-deep-profile: профилирование CPU, кучи и трассировки для горячих точек запуска, Gateway и хода агента. Выполняется по расписанию или при ручном запуске с deep_profile=true.
• live-openai-candidate: реальный ход агента OpenAI openai/gpt-5.6-luna, пропускаемый, когда OPENAI_API_KEY недоступен. Выполняется по расписанию или при ручном запуске с live_openai_candidate=true.

Путь фиктивного провайдера также выполняет собственные исходные проверки OpenClaw после прохождения Kova: время запуска Gateway и использование памяти для случаев запуска по умолчанию, с пропущенным каналом, внутренним перехватчиком и пятьюдесятью плагинами; RSS импорта встроенных плагинов, повторяющиеся циклы приветствия фиктивного OpenAI channel-chat-baseline, команды запуска CLI для запущенного Gateway и дымовую проверку производительности состояния SQLite. Когда для проверяемой ссылки доступен предыдущий опубликованный исходный отчёт фиктивного провайдера, сводка по исходным проверкам сравнивает текущие значения RSS и кучи с этим базовым уровнем и помечает значительное увеличение RSS как watch. Сводка исходных проверок в формате Markdown находится по адресу source/index.md в комплекте отчёта, рядом с необработанным JSON.

Каждый путь загружает полный артефакт GitHub, включая CPU, кучу, трассировку и сжатые диагностические комплекты. Отдельное задание публикации загружает и проверяет эти артефакты, затем создаёт краткосрочный токен GitHub App ClawSweeper с областью действия только для содержимого openclaw/clawgrit-reports и передаёт его исключительно на этап отправки Git. Оно фиксирует report.json, report.md, index.md, артефакты исходных проверок и метаданные/контрольные суммы комплектов в openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/; полный диагностический архив остаётся в связанном артефакте Actions. Задание публикации отклоняет любой файл отчёта размером более 50 МБ до попытки отправки. Текущий указатель проверяемой ссылки — openclaw-performance/<tested-ref>/latest-<lane>.json. Запуски по расписанию и ручные запуски profile=release завершаются с ошибкой, если не удаётся создать токен приложения или опубликовать отчёт. При ручных запусках не для выпуска сбой публикации остаётся рекомендательным, а артефакты GitHub сохраняются при сбое аутентификации или публикации. Предыдущий базовый уровень исходных проверок загружается анонимно из общедоступного репозитория отчётов, поэтому успешная загрузка базового уровня не подтверждает аутентификацию задания публикации.

Полная проверка выпуска

Full Release Validation — сводный рабочий процесс для ручного «запуска всего перед выпуском». Он принимает ветку, тег или полный SHA коммита, запускает вручную рабочий процесс CI с этой целью (включая Android), запускает Plugin Prerelease для предназначенных только для выпуска проверок плагинов, пакетов, статических ресурсов и Docker, запускает OpenClaw Performance для целевого SHA и запускает OpenClaw Release Checks для дымовой проверки установки, приёмки пакета, межплатформенных проверок пакета, соответствия QA Lab, а также путей Matrix и Telegram (рекомендательное формирование карты зрелости включается через run_maturity_scorecard). Стабильный и полный профили всегда включают исчерпывающие живые/E2E-проверки и длительную проверку пути выпуска Docker; для бета-профиля это можно включить через run_release_soak=true. Каноническая E2E-проверка пакета Telegram выполняется внутри приёмки пакета, поэтому полный кандидат не запускает дублирующий живой опросчик. После публикации передайте release_package_spec, чтобы повторно использовать выпущенный пакет npm в проверках выпуска, приёмке пакета, Docker, межплатформенных проверках и Telegram без повторной сборки. Используйте npm_telegram_package_spec только для целевого повторного запуска Telegram с опубликованным пакетом. Путь живой проверки пакета плагина Codex по умолчанию использует то же выбранное состояние: опубликованный release_package_spec=openclaw@<tag> определяет codex_plugin_spec=npm:@openclaw/codex@<tag>, а запуски по SHA/артефакту упаковывают extensions/codex из выбранной ссылки. Явно задайте codex_plugin_spec для пользовательских источников плагина, таких как спецификации npm:, npm-pack: или git:.

Матрицу этапов, точные имена заданий рабочих процессов, различия профилей, артефакты и параметры целевого повторного запуска см. в разделе Полная проверка выпуска.

OpenClaw Release Publish — это выполняемый вручную изменяющий состояние процесс выпуска. Запускайте обычные бета- и стабильные публикации из доверенного main после создания тега выпуска и успешного завершения предварительной проверки OpenClaw в npm (среди прочих проверок она запускает pnpm plugins:sync:check). Тег по-прежнему выбирает точный коммит выпуска, включая коммит в release/YYYY.M.PATCH; альфа-публикации Tideclaw продолжают использовать соответствующую альфа-ветку. Для этого требуются сохранённый preflight_run_id, успешно завершённый full_release_validation_run_id и его точный full_release_validation_run_attempt; затем запускается Plugin NPM Release для всех публикуемых пакетов плагинов, запускается Plugin ClawHub Release для того же SHA выпуска, и только после этого запускается OpenClaw NPM Release. Для стабильной публикации также требуется точный windows_node_tag; процесс проверяет исходный выпуск Windows и сравнивает его установщики x64/ARM64 с одобренными для кандидата входными данными windows_node_installer_digests до запуска любого дочернего процесса публикации, затем продвигает и проверяет те же закреплённые дайджесты установщиков, а также точный контракт сопутствующего ресурса и контрольной суммы перед публикацией черновика выпуска GitHub. Для точечных исправлений только плагинов используйте plugin_publish_scope=selected с непустым списком пакетов. Запуски all-publishable только для плагинов требуют тех же неизменяемых свидетельств предварительной проверки npm и Full Release Validation, что и публикация ядра.

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

Чтобы подтвердить закреплённый коммит в быстро меняющейся ветке, используйте вспомогательную команду вместо gh workflow run ... --ref main -f ref=<sha>:

pnpm ci:full-release --sha <full-sha>

Ссылки запуска процессов GitHub должны быть ветками или тегами, а не необработанными SHA коммитов. Вспомогательная команда отправляет временную ветку release-ci/<sha>-... на доверенном SHA процесса main, передаёт запрошенный целевой SHA через входные данные процесса ref, повторно использует строгие свидетельства для точной цели, когда они доступны, проверяет, что headSha каждого дочернего процесса соответствует доверенному SHA процесса, и удаляет временную ветку после завершения запуска. Передайте -f reuse_evidence=false, чтобы принудительно выполнить новую проверку. Общий верификатор также завершается с ошибкой, если какой-либо дочерний процесс выполнялся с другим SHA процесса.

release_profile управляет охватом рабочих проверок и провайдеров, передаваемым в проверки выпуска. Для запускаемых вручную процессов выпуска по умолчанию используется stable; применяйте full, только если намеренно требуется широкая рекомендательная матрица провайдеров и медиа. Стабильные и полные проверки выпуска всегда выполняют исчерпывающую рабочую/E2E-проверку и длительную проверку пути выпуска Docker; бета-профиль может включить её с помощью run_release_soak=true.

• minimum сохраняет самые быстрые критически важные для выпуска проверки OpenAI/ядра.
• stable добавляет стабильный набор провайдеров и бэкендов.
• full запускает широкую рекомендательную матрицу провайдеров и медиа.

Общий процесс записывает идентификаторы запущенных дочерних процессов, а завершающее задание Verify full validation повторно проверяет текущие результаты дочерних запусков и добавляет таблицы самых медленных заданий для каждого дочернего запуска. Если дочерний процесс перезапущен и успешно завершился, перезапустите только родительское задание верификатора, чтобы обновить результат общего процесса и сводку времени выполнения.

Для восстановления и Full Release Validation, и OpenClaw Release Checks принимают rerun_group. Используйте all для кандидата в выпуск, ci только для обычного дочернего процесса полного CI, plugin-prerelease только для дочернего процесса предварительного выпуска плагинов, performance только для дочернего процесса OpenClaw Performance, release-checks для всех дочерних процессов выпуска или более узкую группу: install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live или npm-telegram в общем процессе. Это ограничивает перезапуск неуспешной среды выпуска после точечного исправления. Для одной неуспешной кроссплатформенной проверки объедините rerun_group=cross-os с cross_os_suite_filter, например windows/packaged-upgrade; длительные кроссплатформенные команды выводят строки Heartbeat, а сводки обновления пакета содержат время выполнения каждого этапа. Проверки выпуска QA носят рекомендательный характер, кроме стандартной проверки охвата инструментов среды выполнения, которая блокирует процесс, если обязательные динамические инструменты OpenClaw расходятся со сводкой стандартного уровня или исчезают из неё.

OpenClaw Release Checks использует доверенную ссылку процесса, чтобы один раз разрешить выбранную ссылку в архив release-package-under-test, а затем передаёт этот артефакт кроссплатформенным проверкам и Package Acceptance, а также рабочему/E2E-процессу Docker для пути выпуска, когда выполняется длительная проверка. Это обеспечивает единообразие байтов пакета во всех средах выпуска и позволяет не перепаковывать одного кандидата в нескольких дочерних заданиях. Для рабочей проверки npm-плагина Codex проверки выпуска либо передают соответствующую спецификацию опубликованного плагина, полученную из release_package_spec, либо передают предоставленный оператором codex_plugin_spec, либо оставляют входные данные пустыми, чтобы скрипт Docker упаковал плагин Codex из выбранной рабочей копии.

Дублирующие запуски Full Release Validation для ref=main и rerun_group=all заменяют более ранний общий процесс. Родительский монитор отменяет все уже запущенные им дочерние процессы при отмене родительского процесса, поэтому новая проверка main не ожидает завершения устаревшей двухчасовой проверки выпуска. Для проверки ветки или тега выпуска и точечных групп перезапуска сохраняется cancel-in-progress: false.

Рабочие и E2E-сегменты

Дочерний рабочий/E2E-процесс выпуска сохраняет широкий охват нативного pnpm test:live, но запускает его как именованные сегменты через scripts/test-live-shard.mjs вместо одного последовательного задания:

• native-live-src-agents и native-live-src-agents-zai-coding
• native-live-src-gateway-core
• отфильтрованные по провайдеру задания native-live-src-gateway-profiles
• native-live-src-gateway-backends
• native-live-src-infra
• native-live-test
• native-live-extensions-a-k
• native-live-extensions-l-n
• native-live-extensions-moonshot
• native-live-extensions-openai
• native-live-extensions-o-z-other
• native-live-extensions-xai
• разделённые сегменты аудио/видео и отфильтрованные по провайдеру музыкальные сегменты

Это сохраняет тот же охват файлов, но упрощает перезапуск и диагностику медленных сбоев рабочих проверок провайдеров. Совокупные имена сегментов native-live-src-gateway, native-live-extensions-o-z, native-live-extensions-media и native-live-extensions-media-music остаются допустимыми для ручных однократных перезапусков.

Нативные рабочие сегменты медиа выполняются в ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04, созданном процессом Live Media Runner Image. В этом образе заранее установлены ffmpeg и ffprobe; задания медиа перед настройкой только проверяют наличие исполняемых файлов. Выполняйте рабочие наборы на базе Docker на обычных исполнителях Blacksmith — задания в контейнерах не подходят для запуска вложенных тестов Docker.

Рабочие сегменты моделей и бэкендов на базе Docker используют отдельный общий образ ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions> для каждого выбранного коммита. Рабочий процесс выпуска один раз собирает и отправляет этот образ, после чего сегменты рабочей модели Docker, Gateway с разделением по провайдерам, бэкенда CLI, привязки ACP и тестового стенда Codex выполняются с OPENCLAW_SKIP_DOCKER_BUILD=1. Сегменты Gateway в Docker используют явные ограничения timeout на уровне скрипта, меньшие тайм-аута задания процесса, чтобы зависший контейнер или путь очистки быстро завершался с ошибкой, а не расходовал весь бюджет проверки выпуска. Если эти сегменты независимо пересобирают полную целевую сборку Docker из исходного кода, запуск выпуска настроен неверно и потратит реальное время на повторную сборку образов.

Package Acceptance

Используйте Package Acceptance, когда нужно ответить на вопрос: «Работает ли этот устанавливаемый пакет OpenClaw как продукт?». Эта проверка отличается от обычного CI: обычный CI проверяет дерево исходного кода, а Package Acceptance проверяет один архив через тот же тестовый стенд E2E в Docker, который используют пользователи после установки или обновления.

Задания

1. resolve_package получает workflow_ref, разрешает одного кандидата пакета, записывает .artifacts/docker-e2e-package/openclaw-current.tgz, записывает .artifacts/docker-e2e-package/package-candidate.json, загружает их как артефакт package-under-test и выводит источник, ссылку процесса, ссылку пакета, версию, SHA-256 и профиль в сводке шага GitHub.
2. package_integrity загружает артефакт package-under-test и обеспечивает соблюдение контракта публичного архива пакета с помощью scripts/check-openclaw-package-tarball.mjs.
3. docker_acceptance вызывает openclaw-live-and-e2e-checks-reusable.yml с разрешённым SHA исходного кода пакета (с переходом к workflow_ref при отсутствии значения) и package_artifact_name=package-under-test. Повторно используемый процесс загружает этот артефакт, проверяет содержимое архива, при необходимости подготавливает образы Docker для дайджеста пакета и запускает выбранные проверки Docker для этого пакета вместо упаковки рабочей копии процесса. Когда профиль выбирает несколько целевых docker_lanes, повторно используемый процесс один раз подготавливает пакет и общие образы, а затем параллельно распределяет эти проверки по целевым заданиям Docker с уникальными артефактами.
4. package_telegram при необходимости вызывает NPM Telegram Beta E2E. Он выполняется, когда telegram_mode не равен none, и устанавливает тот же артефакт package-under-test, если Package Acceptance разрешил его; автономный запуск Telegram по-прежнему может установить опубликованную спецификацию npm.
5. summary завершает процесс с ошибкой, если разрешение пакета, проверка целостности, приёмочная проверка Docker или необязательная проверка Telegram завершились неудачно. Входные данные advisory понижают ошибки приёмочной проверки до предупреждений для рекомендательных вызывающих процессов.

Источники кандидатов

• source=npm принимает только openclaw@extended-stable, openclaw@beta, openclaw@latest или точную версию выпуска OpenClaw, например openclaw@2026.4.27-beta.2. Используйте это для приёмочной проверки опубликованного выпуска с расширенной поддержкой, предварительного или стабильного выпуска.
• source=ref упаковывает доверенную ветку, тег или полный SHA коммита package_ref. Средство разрешения получает ветки и теги OpenClaw, проверяет, что выбранный коммит доступен из истории ветки репозитория или тега выпуска, устанавливает зависимости в отсоединённой рабочей копии и упаковывает её с помощью scripts/package-openclaw-for-docker.mjs.
• source=url загружает публичный HTTPS-ресурс .tgz; package_sha256 обязателен. Этот путь отклоняет учётные данные в URL, нестандартные порты HTTPS, частные, внутренние и служебные имена узлов или разрешённые IP-адреса, а также перенаправления, не соответствующие той же политике публичной безопасности.
• source=trusted-url загружает HTTPS-ресурс .tgz согласно именованной политике доверенного источника в .github/package-trusted-sources.json; package_sha256 и trusted_source_id обязательны. Используйте это только для принадлежащих сопровождающим корпоративных зеркал или частных репозиториев пакетов, которым требуются настроенные узлы, порты, префиксы путей, узлы перенаправления или разрешение адресов частной сети. Если политика объявляет аутентификацию по токену носителя, процесс использует фиксированный секрет OPENCLAW_TRUSTED_PACKAGE_TOKEN; встроенные в URL учётные данные по-прежнему отклоняются.
• source=artifact загружает один .tgz из artifact_run_id и artifact_name; package_sha256 необязателен, но его следует указывать для артефактов, предоставляемых внешним пользователям.

Не объединяйте workflow_ref и package_ref. workflow_ref — это доверенный код процесса и тестового стенда, запускающий тест. package_ref — это исходный коммит, который упаковывается при source=ref. Благодаря этому текущий тестовый стенд может проверять старые доверенные исходные коммиты без запуска старой логики процесса.

Профили наборов

• smoke — npm-onboard-channel-agent, gateway-network, config-reload
• package — npm-onboard-channel-agent, doctor-switch, update-channel-switch, skill-install, update-corrupt-plugin, upgrade-survivor, published-upgrade-survivor, root-managed-vps-upgrade, update-restart-auth, plugins-offline, plugin-update
• product — набор package с рабочим охватом plugins вместо plugins-offline, а также mcp-channels, cron-mcp-cleanup, openai-web-search-minimal, openwebui
• full — полные сегменты пути выпуска Docker с OpenWebUI
• custom — точный docker_lanes; обязателен при suite_profile=custom

Профиль package использует автономное покрытие плагинов, поэтому проверка опубликованного пакета не зависит от доступности ClawHub в реальном времени. Необязательный этап Telegram повторно использует артефакт package-under-test в NPM Telegram Beta E2E, при этом путь со спецификацией опубликованного пакета npm сохраняется для автономных запусков.

Политика специализированного тестирования обновлений и плагинов, включая локальные команды, этапы Docker, входные данные Package Acceptance, параметры выпуска по умолчанию и разбор сбоев, описана в разделе Тестирование обновлений и плагинов.

Проверки выпуска вызывают Package Acceptance с source=artifact, подготовленным артефактом пакета выпуска, suite_profile=custom, docker_lanes='doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape' и telegram_mode=mock-openai. Благодаря этому миграция пакета, обновление, установка Skills из ClawHub в реальном времени, очистка устаревших зависимостей плагинов, восстановление установки настроенных плагинов, автономное тестирование плагинов, обновление плагинов и проверка Telegram выполняются с одним и тем же разрешённым tarball пакета. Задайте release_package_spec в Full Release Validation или OpenClaw Release Checks после публикации бета-версии, чтобы выполнить ту же матрицу для выпущенного пакета npm без повторной сборки; задавайте package_acceptance_package_spec только тогда, когда Package Acceptance требуется пакет, отличный от используемого в остальной проверке выпуска. Межплатформенные проверки выпуска по-прежнему охватывают зависящие от ОС первоначальную настройку, установщик и поведение платформы; проверку продукта на уровне пакета и обновления следует начинать с Package Acceptance.

Этап Docker published-upgrade-survivor проверяет один опубликованный базовый пакет за запуск в блокирующем пути выпуска. В Package Acceptance разрешённый tarball package-under-test всегда является кандидатом, а published_upgrade_survivor_baseline выбирает резервную опубликованную базовую версию, по умолчанию openclaw@latest; команды повторного запуска сбойного этапа сохраняют эту базовую версию. Full Release Validation с run_release_soak=true или release_profile=full задаёт published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15' и published_upgrade_survivor_scenarios=reported-issues, расширяя охват до четырёх последних стабильных выпусков npm, закреплённых граничных выпусков совместимости плагинов и фикстур, воспроизводящих проблемы с конфигурацией Feishu, сохранёнными файлами начальной загрузки и персоны, установками настроенных плагинов OpenClaw, путями журналов с тильдой и устаревшими корнями зависимостей прежних плагинов. Наборы проверок работоспособности после обновления с несколькими опубликованными базовыми версиями разделяются по базовым версиям на отдельные целевые задания исполнителей Docker. Отдельный рабочий процесс Update Migration использует этап Docker update-migration с базовыми версиями all-since-2026.4.23 и сценариями plugin-deps-cleanup, когда требуется исчерпывающая очистка после обновления опубликованных версий, а не обычная широта Full Release CI. Локальным агрегированным запускам можно передать точные спецификации пакетов через OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS, оставить один этап с помощью OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC, например openclaw@2026.4.15, либо задать OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS для матрицы сценариев. Опубликованный этап настраивает базовую версию с помощью встроенного набора команд openclaw config set, записывает шаги набора в summary.json и проверяет /healthz, /readyz, а также состояние RPC после запуска Gateway. Этапы чистой установки упакованной версии и установщика в Windows также проверяют, что установленный пакет может импортировать переопределение управления браузером по необработанному абсолютному пути Windows. Межплатформенная дымовая проверка хода агента OpenAI по умолчанию использует OPENCLAW_CROSS_OS_OPENAI_MODEL, если значение задано, иначе openai/gpt-5.6-luna, поэтому проверка установки и Gateway выполняется на более дешёвом тестовом уровне GPT-5.6.

Периоды совместимости с устаревшими версиями

Package Acceptance предусматривает ограниченные периоды совместимости с уже опубликованными пакетами. Пакеты вплоть до 2026.4.25, включая 2026.4.25-beta.*, могут использовать путь совместимости:

• известные закрытые записи контроля качества в dist/postinstall-inventory.json могут указывать на файлы, отсутствующие в tarball;
• doctor-switch может пропускать подслучай сохранения gateway install --wrapper, если пакет не предоставляет этот флаг;
• update-channel-switch может удалять отсутствующие pnpm patchedDependencies из фиктивной git-фикстуры, созданной на основе tarball, и регистрировать отсутствующие сохранённые update.channel;
• дымовые проверки плагинов могут читать прежние расположения записей установки или допускать отсутствие сохранения записей установки из магазина;
• plugin-update может разрешать миграцию метаданных конфигурации, по-прежнему требуя неизменности записи установки и поведения без повторной установки.

Опубликованный пакет 2026.4.26 также может выдавать предупреждения для уже выпущенных локальных файлов отметок метаданных сборки, а пакеты вплоть до 2026.5.20 могут предупреждать, а не завершаться с ошибкой, если отсутствует npm-shrinkwrap.json. Более поздние пакеты должны соответствовать современным контрактам; при тех же условиях они завершаются с ошибкой, а не предупреждают или пропускают проверку.

Примеры

# Проверить текущий бета-пакет с покрытием на уровне продукта.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 telegram_mode=mock-openai # Проверить опубликованный пакет расширенной стабильной версии с покрытием пакета.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@extended-stable \  -f suite_profile=package \  -f telegram_mode=mock-openai # Упаковать и проверить ветку выпуска с помощью текущей тестовой оснастки.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=ref \  -f package_ref=release/YYYY.M.PATCH \  -f suite_profile=package \  -f telegram_mode=mock-openai # Проверить URL-адрес tarball. Для source=url значение SHA-256 обязательно.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=url \  -f package_url=https://example.com/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # Проверить tarball из именованной политики доверенного закрытого зеркала.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=trusted-url \  -f trusted_source_id=enterprise-artifactory \  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # Повторно использовать tarball, загруженный другим запуском Actions.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=artifact \  -f artifact_run_id=<run-id> \  -f artifact_name=package-under-test \  -f suite_profile=custom \  -f docker_lanes='install-e2e plugin-update'

При отладке сбойного запуска приёмки пакета сначала откройте сводку resolve_package, чтобы проверить источник, версию и SHA-256 пакета. Затем изучите дочерний запуск docker_acceptance и его артефакты Docker: .artifacts/docker-tests/**/summary.json, failures.json, журналы этапов, длительность фаз и команды повторного запуска. Предпочитайте повторный запуск сбойного профиля пакета или конкретных этапов Docker вместо повторного запуска полной проверки выпуска.

Дымовая проверка установки

Рабочий процесс Install Smoke больше не выполняется для запросов на включение изменений или отправок в main. Его ночная или запускаемая вручную обёртка и проверка выпуска вызывают доступное только для чтения ядро install-smoke-reusable.yml, а каждый запуск проходит полный путь дымовой проверки установки на исполнителях GitHub:

• Корневой образ дымовой проверки Dockerfile собирается один раз для каждого целевого SHA, привязывается к редакции рабочего процесса и попытке производителя в неизменяемом артефакте, а затем загружается дымовой проверкой CLI, дымовой проверкой удаления агентами общей рабочей области через CLI, сквозной проверкой сети Gateway контейнера и дымовой проверкой аргумента сборки встроенного плагина matrix. Проверка плагина подтверждает зеркалирование установки зависимостей среды выполнения и загрузку плагина без диагностических сообщений о выходе за пределы точки входа.
• Установка пакета QR и дымовые проверки установщика и обновления в Docker, включая этапы установщика Rocky Linux и этап обновления относительно настраиваемой базовой версии npm update_baseline_version, выполняются как отдельные задания, чтобы работа установщика не ожидала завершения дымовых проверок корневого образа.

Медленная дымовая проверка поставщика образов при глобальной установке Bun отдельно управляется параметром run_bun_global_install_smoke. Она выполняется по ночному расписанию, по умолчанию включена для вызовов рабочего процесса из проверок выпуска, а при ручных запусках Install Smoke её можно включить явно. Обычный CI для запросов на включение изменений по-прежнему выполняет быстрый этап регрессионной проверки средства запуска Bun для изменений, относящихся к Node. Тесты QR и установщика в Docker используют собственные Dockerfile, ориентированные на установку.

Локальная сквозная проверка Docker

pnpm test:docker:all предварительно собирает один общий образ для тестирования в реальном времени, один раз упаковывает OpenClaw в tarball npm и создаёт два общих образа scripts/e2e/Dockerfile:

• минимальный исполнитель Node/Git для этапов установщика, обновления и зависимостей плагинов;
• функциональный образ, устанавливающий тот же tarball в /app для обычных функциональных этапов.

Определения этапов Docker находятся в scripts/lib/docker-e2e-scenarios.mjs, логика планировщика — в scripts/lib/docker-e2e-plan.mjs, а исполнитель только выполняет выбранный план. Планировщик выбирает образ для каждого этапа с помощью OPENCLAW_DOCKER_E2E_BARE_IMAGE и OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE, а затем запускает этапы посредством OPENCLAW_SKIP_DOCKER_BUILD=1.

Настраиваемые параметры

Этап, требующий больше ресурсов, чем допускает его действующее ограничение, всё равно может запуститься из пустого пула, после чего выполняется в одиночку до освобождения ресурсов. Локальный агрегированный запуск предварительно проверяет Docker, удаляет устаревшие контейнеры сквозной проверки OpenClaw, выводит состояние активных этапов, сохраняет длительность этапов для упорядочивания от самых долгих к самым коротким и по умолчанию прекращает планирование новых этапов пула после первого сбоя.

Повторно используемый рабочий процесс проверки в реальном времени и сквозного тестирования

Повторно используемый рабочий процесс проверки в реальном времени и сквозного тестирования запрашивает у scripts/test-docker-all.mjs --plan-json, какой пакет, вид образа, образ для проверки в реальном времени, этап и охват учётных данных требуются. Затем scripts/docker-e2e.mjs преобразует этот план в выходные данные и сводки GitHub. Он либо упаковывает OpenClaw через scripts/package-openclaw-for-docker.mjs, либо загружает артефакт пакета текущего запуска, либо загружает артефакт пакета из package_artifact_run_id, после чего проверяет содержимое tarball. Путь no-push-artifact, используемый по умолчанию, собирает минимальный и функциональный образы с тегами на основе дайджеста пакета через кэш слоёв Docker от Blacksmith, упаковывает точные байты образов в неизменяемый артефакт рабочего процесса и требует от каждого потребителя проверить и загрузить этот артефакт. Вариант existing-only вместо этого требует явных ссылок GHCR docker_e2e_bare_image/docker_e2e_functional_image и никогда не выполняет сборку или отправку. Для таких загрузок из реестра установлен ограниченный тайм-аут 180 секунд на попытку, чтобы зависший поток быстро перезапускался, а не занимал бо́льшую часть критического пути CI. После успешной запланированной проверки openclaw-scheduled-live-checks.yml передаёт неизменяемый манифест проверенного образа отдельному процессу публикации с правом записи пакетов; вызывающие процессы выпуска и предварительного выпуска с доступом только для чтения никогда не проходят через этот процесс записи.

Части пути выпуска

Покрытие Docker для релизов выполняется небольшими заданиями, разбитыми на части с помощью OPENCLAW_SKIP_DOCKER_BUILD=1, поэтому каждая часть проверяет и загружает только необходимый ей тип образа на основе артефакта (или получает его при явном повторном использовании existing-only) и запускает несколько направлений через один и тот же взвешенный планировщик:

• OPENCLAW_DOCKER_ALL_PROFILE=release-path
• OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui

Текущие части Docker для релизов: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, с plugins-runtime-install-a по plugins-runtime-install-h и openwebui. package-update-openai включает направление пакета плагина Codex с реальным подключением: оно устанавливает пакет-кандидат OpenClaw, устанавливает плагин Codex из codex_plugin_spec или tar-архива из той же ссылки с явным разрешением на установку Codex CLI, выполняет предварительную проверку Codex CLI, а затем запускает несколько последовательных обращений агента OpenClaw в одном сеансе к OpenAI. plugins-runtime-core, plugins-runtime и plugins-integrations остаются агрегированными псевдонимами плагинов и сред выполнения. Псевдоним направления install-e2e остаётся агрегированным псевдонимом ручного повторного запуска для обоих направлений установщика провайдера.

OpenWebUI запускается как отдельная часть openwebui на выделенном исполнителе Blacksmith с большим диском всякий раз, когда это требуется для стабильного релиза или полного покрытия пути выпуска, даже если переиспользуемый рабочий процесс направляет поддерживаемые задания на исполнители GitHub. Отдельная загрузка внешнего образа предотвращает конкуренцию большого образа с общими образами пакета и плагина в plugins-runtime-services; устаревшие агрегированные части плагинов и сред выполнения по-прежнему включают OpenWebUI для совместимых ручных повторных запусков. Направления обновления встроенных каналов выполняют одну повторную попытку при временных сетевых сбоях npm.

Каждая часть загружает .artifacts/docker-tests/ с журналами направлений, замерами времени, summary.json, failures.json, замерами времени фаз, JSON-планом планировщика, таблицами медленных направлений и командами повторного запуска для каждого направления. Входной параметр docker_lanes рабочего процесса запускает выбранные направления на образах, подготовленных для этого запуска, вместо заданий отдельных частей, что ограничивает отладку сбойного направления одним целевым заданием Docker; если выбранное направление является Docker-направлением с реальным подключением, целевое задание локально собирает образ для тестирования с реальным подключением для этого повторного запуска. Вспомогательный инструмент повторного запуска проверяет точный целевой SHA выбранного артефакта сбоя, а ручной запуск повторно упаковывает эту ссылку, поскольку внутренний кортеж пакета переиспользуемого рабочего процесса не входит в схему workflow_dispatch. Сгенерированные команды включают входные параметры подготовленных образов и shared_image_policy=existing-only только тогда, когда эти параметры ссылаются на GHCR; локальные для исполнителя теги артефактов опускаются, чтобы новый исполнитель пересобрал их. При явном переопределении цели восстановленные ссылки на образы GHCR удаляются, если артефакт не подтверждает их соответствие переопределению. Сгенерированные из артефактов ссылки на определения рабочих процессов также опускаются, поскольку временные ветви полного релиза удаляются; запуск использует ветвь репозитория по умолчанию, если оператор явно не переопределит её.

pnpm test:docker:rerun <run-id>      # загрузить артефакты Docker и вывести объединённые и отдельные для направлений команды целевого повторного запускаpnpm test:docker:timings <summary>   # сводки медленных направлений и критического пути фаз

Запланированный рабочий процесс с реальным подключением и E2E ежедневно запускает полный набор Docker для пути выпуска и после его успешного завершения вызывает явный издатель для точных артефактов протестированных образов.

Предварительный выпуск плагинов

Plugin Prerelease обеспечивает более ресурсоёмкое покрытие продукта и пакетов, поэтому это отдельный рабочий процесс, запускаемый через Full Release Validation или явно оператором. Для обычных запросов на включение изменений, отправок в main и автономных ручных запусков CI этот набор отключён. Он распределяет тесты встроенных плагинов между восемью исполнителями расширений; задания этих сегментов расширений одновременно запускают до двух групп конфигураций плагинов с одним исполнителем Vitest на группу и увеличенной кучей Node, чтобы пакеты плагинов с интенсивным импортом не создавали дополнительные задания CI. Предрелизный путь Docker только для релизов, включаемый входным параметром full_release_validation, объединяет целевые Docker-направления в группы по четыре, чтобы не резервировать десятки исполнителей для заданий продолжительностью от одной до трёх минут. Рабочий процесс также загружает информационный артефакт plugin-inspector-advisory из @openclaw/plugin-inspector; результаты инспектора используются для сортировки и не влияют на блокирующую проверку предварительного выпуска плагинов.

Лаборатория контроля качества

У QA Lab есть выделенные направления CI вне основного рабочего процесса с интеллектуальным выбором области. Паритет агентных возможностей вложен в общие средства контроля качества и выпуска, а не оформлен как отдельный рабочий процесс для запросов на включение изменений. Используйте Full Release Validation вместе с rerun_group=qa-parity, если паритет должен проверяться в составе широкого запуска валидации.

• Рабочий процесс QA-Lab - All Lanes запускается каждую ночь по main и вручную; он параллельно распределяет направление имитации паритета, направление Matrix с реальным подключением, а также направления Telegram и Discord с реальным подключением. Задания с реальным подключением используют окружение qa-live-shared, а Telegram и Discord используют аренды Convex.

Проверки выпуска запускают транспортные направления Matrix и Telegram с реальным подключением, используя детерминированный имитационный провайдер и модели с квалификатором имитации (mock-openai/gpt-5.6-luna и mock-openai/gpt-5.6-luna-alt), чтобы изолировать контракт канала от задержки реальной модели и обычного запуска плагина провайдера. Gateway транспорта с реальным подключением отключает поиск по памяти, поскольку QA-паритет проверяет поведение памяти отдельно; подключение к провайдерам проверяется отдельными наборами реальных моделей, нативных провайдеров и Docker-провайдеров.

Matrix использует --profile fast для запланированных проверок и проверок выпуска, добавляя --fail-fast только тогда, когда извлечённая версия CLI его поддерживает. Значением по умолчанию для CLI и входного параметра ручного рабочего процесса остаётся all; ручной запуск matrix_profile=all всегда разбивает полное покрытие Matrix на задания transport, media, e2ee-smoke, e2ee-deep и e2ee-cli.

OpenClaw Release Checks также запускает критически важные для выпуска направления QA Lab до утверждения выпуска; его проверка QA-паритета запускает наборы кандидата и базовой версии как параллельные задания направлений, а затем загружает оба артефакта в небольшое задание отчёта для окончательного сравнения паритета.

Для обычных запросов на включение изменений следуйте свидетельствам проверок и CI для соответствующей области, а не рассматривайте паритет как обязательный статус.

CodeQL

Рабочий процесс CodeQL намеренно представляет собой узкий сканер безопасности первого прохода, а не полное сканирование репозитория. Ежедневные и ручные запуски, отправки в main и защитные запуски для запросов на включение изменений без статуса черновика сканируют код рабочих процессов Actions и наиболее рискованные области JavaScript/TypeScript с помощью высокоточных запросов безопасности, отфильтрованных до уровней security-severity high/critical.

Защитная проверка запросов на включение изменений остаётся облегчённой: она запускается только для изменений в .github/actions, .github/codeql, .github/workflows, packages, scripts, src или в путях сред выполнения встроенных плагинов, управляющих процессами, и выполняет ту же матрицу высокоточных проверок безопасности, что и запланированный рабочий процесс. CodeQL для Android и macOS не входит в проверки запросов на включение изменений по умолчанию.

Категории безопасности

Сегменты безопасности для отдельных платформ

• CodeQL Android Critical Security — запланированный сегмент безопасности Android. Вручную собирает приложение Android для CodeQL на самом малом исполнителе Blacksmith Linux, допустимом проверкой корректности рабочего процесса. Загружает под именем /codeql-critical-security/android.
• CodeQL macOS Critical Security — еженедельный или ручной сегмент безопасности macOS. Вручную собирает приложение macOS для CodeQL в Blacksmith macOS, исключает результаты сборки зависимостей из загружаемого SARIF и загружает под именем /codeql-critical-security/macos. Не входит в ежедневные проверки по умолчанию, поскольку сборка macOS занимает основную часть времени выполнения даже при отсутствии проблем.

Критические категории качества

CodeQL Critical Quality — соответствующий сегмент, не связанный с безопасностью. Он выполняет только запросы качества JavaScript/TypeScript, не связанные с безопасностью и имеющие уровень серьёзности error, для узких высокоприоритетных областей на Linux-исполнителях GitHub, чтобы проверки качества не расходовали бюджет регистрации исполнителей Blacksmith. Его защитная проверка запросов на включение изменений намеренно уже запланированного профиля: запросы без статуса черновика запускают только соответствующие сегменты для затронутых областей из тринадцати сегментов, доступных для маршрутизации запросов: agent-runtime-boundary, channel-runtime-boundary, config-boundary, core-auth-secrets, gateway-runtime-boundary, mcp-process-runtime-boundary, memory-runtime-boundary, network-runtime-boundary, plugin-boundary, plugin-sdk-package-contract, plugin-sdk-reply-runtime, provider-runtime-boundary и session-diagnostics-boundary. ui-control-plane и web-media-runtime-boundary не запускаются для запросов на включение изменений. Изменения конфигурации CodeQL и рабочего процесса качества запускают полный набор сегментов запросов на включение изменений (сегмент сетевой среды выполнения активируется собственными файлами конфигурации CodeQL и путями исходного кода, управляющими сетью).

Ручной запуск принимает:

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

Узкие профили служат средствами обучения и итеративной разработки для изолированного запуска одного сегмента качества.

Качество отделено от безопасности, чтобы результаты проверок качества можно было планировать, измерять, отключать или расширять, не затрудняя восприятие сигналов безопасности. Расширение CodeQL для Swift, Python и плагинов из комплекта поставки следует вернуть в виде ограниченной по области или разделённой на сегменты последующей работы только после того, как узкие профили обеспечат стабильные время выполнения и сигналы.

Рабочие процессы обслуживания

Агент документации

Рабочий процесс Docs Agent — это управляемая событиями линия обслуживания Codex, поддерживающая соответствие существующей документации недавно внесённым изменениям. У неё нет запуска только по расписанию: её может инициировать успешный запуск CI после отправки изменений не ботом в main, а ручной запуск позволяет выполнить её напрямую. Запуски, инициированные другим рабочим процессом, пропускаются, если main уже изменился или если за последний час был создан другой непропущенный запуск агента документации. При выполнении он проверяет диапазон коммитов от SHA источника предыдущего непропущенного запуска агента документации до текущего main, поэтому один ежечасный запуск может охватить все изменения основной ветки, накопившиеся с момента предыдущей проверки документации.

Агент производительности тестов

Рабочий процесс Test Performance Agent — это управляемая событиями линия обслуживания Codex для медленных тестов. У неё нет запуска только по расписанию: её может инициировать успешный запуск CI после отправки изменений не ботом в main, но она пропускается, если другой запуск рабочего процесса уже выполнялся или выполняется в этот день по UTC. Ручной запуск обходит это суточное ограничение активности. Линия формирует сгруппированный отчёт о производительности полного набора Vitest, позволяет Codex вносить только небольшие оптимизации производительности тестов с сохранением покрытия вместо масштабных рефакторингов, затем повторно формирует отчёт полного набора и отклоняет изменения, уменьшающие исходное количество успешно пройденных тестов. Сгруппированный отчёт записывает фактическое время выполнения и максимальный RSS для каждой конфигурации в Linux и macOS, поэтому сравнение до и после показывает изменения потребления памяти тестами рядом с изменениями длительности. Если в исходном состоянии есть непройденные тесты, Codex может исправлять только очевидные сбои, а отчёт полного набора после работы агента должен завершиться успешно до фиксации каких-либо изменений. Если main продвигается до отправки изменений ботом, линия перебазирует проверенный патч, повторно запускает pnpm check:changed и повторяет попытку отправки; конфликтующие устаревшие патчи пропускаются. Она использует размещённый на GitHub Ubuntu, чтобы действие Codex могло сохранить ту же безопасную политику удаления sudo, что и агент документации.

Дубликаты PR после слияния

Рабочий процесс Duplicate PRs After Merge — это запускаемый вручную сопровождающим рабочий процесс для очистки дубликатов после внесения изменений. По умолчанию он работает в режиме пробного запуска и закрывает только явно перечисленные PR, если apply=true. Перед изменением данных на GitHub он проверяет, что внесённый PR объединён и что каждый дубликат либо ссылается на ту же задачу, либо содержит пересекающиеся изменённые фрагменты.

gh workflow run duplicate-after-merge.yml \  -f landed_pr=70532 \  -f duplicate_prs='70530,70592' \  -f apply=true

Локальные контрольные проверки и маршрутизация изменений

Логика локальных линий для изменений находится в scripts/changed-lanes.mjs и выполняется посредством scripts/check-changed.mjs. Эта локальная контрольная проверка строже относится к архитектурным границам, чем широкая область платформы CI:

• изменения производственного кода ядра запускают проверку типов производственного и тестового кода ядра, а также линтер и защитные проверки ядра;
• изменения только тестов ядра запускают лишь проверку типов тестового кода ядра и линтер ядра;
• изменения производственного кода расширений запускают проверку типов производственного и тестового кода расширений, а также линтер расширений;
• изменения только тестов расширений запускают проверку типов тестового кода расширений и линтер расширений;
• изменения публичного Plugin SDK или контрактов плагинов расширяют проверку типов на расширения, поскольку расширения зависят от этих контрактов ядра (проверки расширений Vitest остаются явно выполняемой тестовой работой);
• изменения версий только в метаданных релиза запускают целевые проверки версий, конфигурации и корневых зависимостей;
• неизвестные изменения корня или конфигурации для безопасности запускают все линии проверок.

Локальная маршрутизация изменённых тестов находится в scripts/test-projects.test-support.mjs и намеренно обходится дешевле, чем check:changed: непосредственно изменённые тесты запускаются сами, для изменений исходного кода сначала используются явные сопоставления, затем одноуровневые тесты и зависимые элементы графа импортов. Общая конфигурация доставки для групповых комнат входит в число явных сопоставлений: изменения конфигурации видимых ответов группы, режима доставки исходных ответов или системной подсказки инструмента сообщений направляются через основные тесты ответов, а также регрессионные тесты доставки Discord и Slack, чтобы изменение общего значения по умолчанию завершалось с ошибкой до первой отправки PR. Используйте OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed только тогда, когда изменение настолько широко затрагивает тестовую инфраструктуру, что дешёвый сопоставленный набор не является надёжным приближением.

Проверка в Testbox

Crabbox — это принадлежащая репозиторию обёртка удалённой среды для проверки сопровождающими в Linux. Сеансы агентов по умолчанию используют её для тестов и вычислительно затратной работы, включая сборки, проверки типов, параллельные запуски линтера, Docker, линии пакетов, E2E, проверку в реальной среде и соответствие CI. Для доверенного кода сопровождающих по умолчанию используется blacksmith-testbox, и .crabbox.yaml теперь также использует его по умолчанию. Настроенный рабочий процесс загружает учётные данные провайдеров и агентов, поэтому недоверенный код участников или форков должен использовать CI форка без секретов либо очищенную прямую среду AWS Crabbox. Очищенные запуски AWS задают CRABBOX_ENV_ALLOW=CI, передают --no-hydrate и используют временный удалённый HOME; это не позволяет списку разрешений репозитория OPENCLAW_* и существующим профилям аутентификации стать доступными недоверенному коду. Они используют только что прогретую аренду, выделенную для этого недоверенного исходного кода, и никогда не используют доверенную или ранее снабжённую учётными данными аренду. Запускайте установленный доверенный двоичный файл Crabbox из чистой доверенной рабочей копии main и получайте только удалённый PR с помощью --fresh-pr; никогда не выполняйте локально обёртку или конфигурацию из недоверенной рабочей копии. Удалите CRABBOX_AWS_INSTANCE_PROFILE и прекращайте работу в безопасном режиме, если разрешённое значение aws.instanceProfile не пусто. Перед любой установкой или тестом используйте доверенные инструменты с абсолютными путями, чтобы потребовать токен IMDSv2, подтвердить, что конечная точка учётных данных IAM возвращает 404, и сравнить удалённый git rev-parse HEAD с полным проверенным SHA вершины PR. Привяжите аренду к этому SHA и остановите и прогрейте её заново при изменении вершины. Загрузите доверенный scripts/crabbox-untrusted-bootstrap.sh из чистой main вместе с --fresh-pr; он устанавливает закреплённые версии Node и pnpm, проверяет SHA и закреплённую версию менеджера пакетов, изолирует HOME, устанавливает зависимости, а затем выполняет запрошенный тест. Удалите все переопределения CRABBOX_TAILSCALE*, принудительно задайте --network public --tailscale=false, очистите флаги выходного узла и локальной сети и потребуйте, чтобы crabbox inspect сообщал о публичной сети без состояния Tailscale, прежде чем загружать какой-либо скрипт. Собственные ресурсы AWS и Hetzner также остаются резервным вариантом при сбоях Blacksmith, проблемах с квотами или явно запрошенном тестировании на собственных ресурсах.

В начале задачи с доверенным кодом, для которой, вероятно, потребуются тесты или ресурсоёмкая проверка, агентам следует немедленно начать предварительный прогрев в фоновом сеансе команд, продолжить проверку и редактирование во время загрузки среды, повторно использовать возвращённый идентификатор tbx_..., синхронизировать текущую рабочую копию при каждом запуске и остановить её перед передачей результата:

node scripts/crabbox-wrapper.mjs warmup --provider blacksmith-testbox --keep --timing-json

Запуски Blacksmith через Crabbox прогревают, резервируют, синхронизируют, выполняют, формируют отчёт и очищают одноразовые Testbox. Встроенная проверка корректности синхронизации немедленно завершается с ошибкой, когда git status --short в синхронизированной среде показывает не менее 200 удалений отслеживаемых файлов, что позволяет обнаружить исчезновение корневых файлов, таких как pnpm-lock.yaml. Для PR с намеренным массовым удалением задайте CRABBOX_ALLOW_MASS_DELETIONS=1 для удалённой команды.

Crabbox также завершает локальный вызов CLI Blacksmith, который остаётся на этапе синхронизации более пяти минут без вывода после синхронизации. Задайте CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0, чтобы отключить эту защиту, или укажите большее значение в миллисекундах для необычно крупных локальных различий.

Перед первым запуском проверьте обёртку из корня репозитория:

pnpm crabbox:run -- --help | sed -n '1,120p'

Обёртка репозитория отклоняет устаревший двоичный файл Crabbox, который не объявляет выбранного провайдера, а для запусков на базе Blacksmith требуется Crabbox 0.22.0 или новее, чтобы обёртка использовала актуальное поведение синхронизации, очереди и очистки Testbox. В рабочих деревьях Codex или связанных и разреженных рабочих копиях избегайте локального скрипта pnpm crabbox:run, поскольку pnpm может начать согласование зависимостей до запуска Crabbox; вместо этого вызывайте обёртку Node напрямую:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

При использовании соседней рабочей копии перед измерением времени или проверкой пересоберите игнорируемый локальный двоичный файл:

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

Блок blacksmith: в .crabbox.yaml уже закрепляет значения организации, рабочего процесса, задания и ссылки по умолчанию, поэтому явные флаги ниже необязательны. Проверка изменений:

pnpm crabbox:run -- --provider blacksmith-testbox \  --blacksmith-org openclaw \  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \  --blacksmith-job check \  --blacksmith-ref main \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm check:changed"

Повторный запуск выбранного теста:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test <path-or-filter>"

Полный набор тестов:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test"

Прочитайте итоговую сводку в формате JSON. Полезные поля: provider, leaseId, syncDelegated, exitCode, commandMs и totalMs. Для делегированных запусков Blacksmith Testbox результатом команды считаются код завершения обёртки Crabbox и сводка JSON. Связанный запуск GitHub Actions отвечает за подготовку и поддержание активности; он может завершиться со статусом cancelled, если Testbox остановлен извне после того, как команда SSH уже завершилась. Считайте это артефактом очистки или статуса, если только значение exitCode обёртки не отлично от нуля или вывод команды не указывает на сбой теста. Одноразовые запуски Crabbox на базе Blacksmith должны автоматически останавливать Testbox; если запуск был прерван или состояние очистки неясно, проверьте активные среды и остановите только созданные вами:

blacksmith testbox list --allblacksmith testbox status --id <tbx_id>blacksmith testbox stop --id <tbx_id>

Используйте повторное использование только тогда, когда намеренно требуется выполнить несколько команд в одной и той же подготовленной среде:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"pnpm crabbox:stop -- <tbx_id>

Повторно используйте аренду, а не устаревший исходный код. Не указывайте --no-sync, чтобы каждый запуск загружал текущую рабочую копию; используйте его только для намеренного повторного запуска неизменённого, уже синхронизированного дерева. Недоверенный код участника или форка должен использовать CRABBOX_ENV_ALLOW=CI, --provider aws --no-hydrate и свежий временный удалённый HOME для каждой команды; устанавливайте зависимости внутри этой санитизированной команды до запуска тестов. Повторно используйте только недавно подготовленную аренду, выделенную для того же недоверенного исходного кода; никогда не используйте доверенную или ранее подготовленную аренду. Никогда не выполняйте локально обёртку или конфигурацию из недоверенной рабочей копии: запускайте установленный доверенный бинарный файл Crabbox из чистой доверенной main и передавайте --fresh-pr при каждом запуске. Не задавайте CRABBOX_AWS_INSTANCE_PROFILE, отклоняйте непустой разрешённый профиль экземпляра, требуйте доверенное удалённое подтверждение IMDS об отсутствии роли и проверяйте SHA проверенной головной ревизии перед установкой и тестированием. Привяжите аренду к этому SHA; после любого изменения головной ревизии остановите и подготовьте её заново. Если удалённого PR нет, используйте CI форка без секретов. Никогда не выбирайте hydrate-github или насыщенный учётными данными рабочий процесс Blacksmith для недоверенного исходного кода.

Если неисправен слой Crabbox, но сам Blacksmith работает, используйте Blacksmith напрямую только для диагностики, например list, status, и очистки. Исправьте путь Crabbox, прежде чем считать прямой запуск Blacksmith доказательством для сопровождающего.

Если blacksmith testbox list --all и blacksmith testbox status работают, но новые подготовки остаются в состоянии queued без IP-адреса или URL запуска Actions спустя пару минут, расценивайте это как нагрузку на поставщика Blacksmith, очередь, биллинг или ограничения организации. Остановите созданные вами идентификаторы в очереди, не запускайте дополнительные Testbox и перенесите проверку на указанный ниже путь собственных мощностей Crabbox, пока кто-либо проверяет панель управления Blacksmith, биллинг и ограничения организации.

Переходите на собственные мощности Crabbox только в том случае, если Blacksmith недоступен, ограничен квотой, не предоставляет необходимое окружение или использование собственных мощностей является явной целью:

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90mpnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

При нагрузке на AWS избегайте class=beast, если задаче действительно не требуется процессор класса 48xlarge. Запрос beast начинается со 192 виртуальных ЦП и является самым простым способом превысить региональную квоту EC2 Spot или On-Demand Standard. Принадлежащий репозиторию .crabbox.yaml по умолчанию использует class: standard, рынок on-demand и capacity.hints: true, чтобы арендованные через брокер ресурсы AWS выводили выбранные регион и рынок, нагрузку на квоту, переход с Spot и предупреждения о классах с высокой нагрузкой. Используйте fast для более тяжёлых широких проверок, large — только если standard/fast недостаточно, а beast — только для исключительных задач, ограниченных производительностью ЦП, таких как полный набор тестов или Docker-матрицы всех плагинов, явная проверка релиза или блокирующей проблемы либо профилирование производительности с большим числом ядер. Не используйте beast для pnpm check:changed, выбранных тестов, работы только с документацией, обычной проверки lint или типов, небольших воспроизведений E2E или диагностики сбоя Blacksmith. Для диагностики мощностей используйте --market on-demand, чтобы колебания рынка Spot не смешивались с сигналом.

.crabbox.yaml определяет поставщика, синхронизацию и значения по умолчанию для подготовки GitHub Actions. Синхронизация Crabbox никогда не передаёт .git, поэтому подготовленная рабочая копия Actions сохраняет собственные удалённые метаданные Git вместо синхронизации локальных удалённых репозиториев и хранилищ объектов сопровождающего, а конфигурация репозитория дополнительно исключает локальные артефакты среды выполнения и сборки (такие как .artifacts и отчёты о тестах), которые никогда не следует передавать. .github/workflows/crabbox-hydrate.yml отвечает за получение рабочей копии, настройку Node/pnpm, получение origin/main и передачу несекретного окружения для команд crabbox run --id <cbx_id> в собственном облаке.

Связанные материалы

• Обзор установки
• Каналы разработки