Переменные CI и релиза

Несколько параметров конвейеров CI и релиза доступны как переменные репозитория GitHub Actions (контекст vars.*), чтобы операторы могли настраивать их без создания pull request. На этой странице перечислены переменные, влияющие на выполнение тестов в .github/workflows/ci.yml и .github/workflows/release.yml, а также их значения по умолчанию и области применения.

Настройка переменной

Сопровождающие репозитория настраивают их в разделе Settings → Secrets and variables → Actions → Variables. Для неустановленной (или пустой) переменной используется фолбэк в выражении workflow. Лимит воркеров применяется только на зарезервированных runner’ах, даже если соответствующая переменная установлена.

Файлы workflow являются источником истины для этих параметров, а тестовые наборы фиксируют выражения workflow побайтно: scripts/tests/package-scripts.test.js фиксирует общее выражение лимита воркеров в release.yml (QWEN_CI_VITEST_MAX_WORKERS с защитой ecs-qwen-), scripts/tests/no-ak-integration-ci.test.js фиксирует выражение лимита воркеров в ci.yml, а scripts/tests/release-workflow.test.js фиксирует выражения таймаутов повторов и тестов workspace в release.yml. scripts/tests/package-scripts.test.js также проверяет задокументированные значения по умолчанию и расположение параметров в обоих workflow. Поскольку эта проверка выполняется в полной CI-ветке (test:scripts), а не только в проверках документации, проверяйте изменения, касающиеся этой страницы, локально перед созданием pull request с помощью npm run test:scripts (или npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/package-scripts.test.js). Если документация и workflow когда-либо расходятся, руководствуйтесь workflow и обновите эту страницу в том же изменении.

Переменные

Счетчики повторов

QWEN_CI_VITEST_RETRY и QWEN_RELEASE_VITEST_RETRY передаются в Vitest как --retry=<n> в основном шаге тестирования CI (test:ci каждого workspace, который этот шаг запускает в двух параллельных ветках, и npm run test:scripts:unit) и в релизной ветке (npm run test:release:workspaces) соответственно. У двух веток разные переменные, чтобы их можно было настраивать независимо.

Vitest перезапускает упавшие тесты в рамках одного запуска. Это может помочь при периодической конкуренции за ресурсы, но если сбой устраняется в рамках бюджета повторов, проверка становится зелёной и не фиксируется трекером нестабильных перезапусков как сбой. Устанавливайте скромный бюджет, а не используйте повторы для маскировки нестабильного набора тестов. Обе переменные также принимают буквальное значение off, которое полностью опускает флаг --retry вместо передачи --retry=0 (командный флаг --retry=0 переопределяет собственную конфигурацию Vitest workspace и отключил бы преднамеренную политику повторов).

Таймаут тестов workspace

QWEN_RELEASE_WORKSPACE_TIMEOUT_MINUTES задаёт timeout-minutes на уровне задания для каждого из трёх шардов workspace_tests в конвейере релиза. Таймаут определяется загрузкой зарезервированного хоста, а не самого набора тестов, поэтому увеличивайте его при высокой загрузке хоста, а не предполагайте регрессию тестов.

Лимит воркеров Vitest на self-hosted runner’ах

QWEN_CI_VITEST_MAX_WORKERS ограничивает количество процессов Vitest в перечисленных ниже шагах (VITEST_MAX_THREADS / VITEST_MAX_FORKS, с минимальным значением, принудительно установленным в 1) на зарезервированных self-hosted runner’ах, чьи имена начинаются с ecs-qwen-. Переменная экспортируется только основным шагом тестирования workspace в CI и шагами workspace_tests и quality_scripts в релизе; другие интеграционные тесты, использующие Vitest и попадающие на тот же зарезервированный пул в workflow CI и релиза, не потребляют её — они используют собственные ограничения Vitest. Web-shell E2E smoke запускается в пуле ARM64 с собственными двумя воркерами Playwright, поэтому лимит на него не распространяется. На runner’ах GitHub переменная игнорируется, и Vitest использует собственные значения по умолчанию.

Каждый запуск Vitest применяет лимит самостоятельно. Основной шаг тестирования workspace в CI запускает две ветки одновременно (.github/scripts/ci/run-unit-test-lanes.sh): основная ветка запускает наборы тестов CLI и core с лимитом, а побочная ветка запускает наборы тестов остальных workspace и npm run test:scripts:unit с половиной лимита, но не менее 1, поэтому в пике шаг выполняет лимит плюс эту половину. На runner’ах GitHub побочной ветки Vitest использует 2 воркера.

Шаг выполняется в двух шардах (Linux unit tests (shard N/2)), каждый из которых передаёт --shard=N/2 в каждый запуск Vitest. Шарды также применяют лимит самостоятельно, поэтому пул видит до двух таких шагов одновременно. Они устанавливаются без сборки prepare и распаковывают дерево, собранное один раз заданием test_build. Test (ubuntu-latest, Node 22.x) проходит только когда сборка и каждый шард проходят успешно.

test_build — единственное задание, которое выполняет сборку. Оно работает через scripts/ci-build-cache.mjs: pull request восстанавливает сборку, сохранённую push’ем в main базового коммита (key --at <base>), с фолбэком на самую новую кэшированную сборку, и пересобирает только те workspace, чьи входные данные изменились: отслеживаемые файлы workspace кроме тестов, корневые файлы, patches/ и scripts/ вне scripts/tests/, а также workspace’ы, от которых он зависит. Push в main всегда выполняет сборку с нуля и сохраняет её. Ключ кэша не несёт архитектуру CPU: пул с меткой x64 включает хосты ARM64, и единственные архитектурно-зависимые выходные данные — нативная библиотека opentui бандла — пересобираются для хоста после каждого восстановления и распаковки (ci-build-cache.mjs host-assets).

Шарды unit-тестов, два шарда Integration Tests (no-AK, shard N/2) и два шарда web-shell smoke распаковывают это единственное дерево. test_build также запускает проверки, которые его читают: serve fast-path bundle closure, экспорты core subpath и проверку свежести settings-schema, для которой Lint & Static раньше выполнял сборку. Integration Tests (no-AK, No Sandbox) проходит только когда сборка и каждый интеграционный шард проходят успешно. Draft pull request пропускает интеграционные шарды и browser smoke; отметка его готовым к ревью запускает прогон, который их включает. Изменение, ограниченное packages/managed-agent-server/ или packages/sdk-java/ (кроме файлов, которые читают наборы тестов TypeScript), классифицируется как java_only: Lint & Static запускает свою нагрузку плюс наборы scripts/tests, которые именуют эти деревья, а сборка и тестирование TypeScript пропускаются.

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

release.yml также предоставляет QWEN_RELEASE_STATIC_TIMEOUT_MINUTES (по умолчанию 60, управляет веткой статического линтинга quality_static) и QWEN_RELEASE_BUILD_TIMEOUT_MINUTES (по умолчанию 45, управляет веткой сборки артефактов quality_build). Поскольку они регулируют статический линтинг и сборку артефактов, а не выполнение тестов, они выходят за рамки выполнения тестов, описанных на этой странице.