CIとリリースの変数

CIおよびリリースパイプラインのいくつかの設定は、GitHub Actionsのリポジトリ変数（vars.*コンテキスト）として公開されているため、オペレーターはプルリクエストを開かずにそれらを再調整できます。このページでは、.github/workflows/ci.ymlと.github/workflows/release.ymlでのテスト実行に影響する変数とそのデフォルト値、および各変数が適用される場所を一覧にまとめています。

変数の設定

リポジトリのメンテナーは、Settings → Secrets and variables → Actions → Variables でこれらを設定します。未設定（または空）の変数は、ワークフロー式のフォールバックを使用します。ワーカーキャップは、変数が設定されている場合でも、予約済みランナー上でのみ適用されます。

ワークフローファイルがこれらの設定の唯一の信頼できる情報源であり、テストスイートはワークフロー式をバイト単位で正確に固定しています。scripts/tests/package-scripts.test.jsはrelease.ymlの共有ワーカーキャップ式（ecs-qwen-ガード付きのQWEN_CI_VITEST_MAX_WORKERS）を固定し、scripts/tests/no-ak-integration-ci.test.jsはci.ymlのワーカーキャップ式を固定し、scripts/tests/release-workflow.test.jsはrelease.ymlのリトライおよびワークスペーステストのタイムアウト式を固定しています。scripts/tests/package-scripts.test.jsは、ドキュメント化されたデフォルト値とワークフローの場所を両方のワークフローに対してチェックします。このガードはドキュメントのみのチェックではなくフルプロファイルCIレーン（test:scripts）で実行されるため、このページのみに限定された編集は、プルリクエストを開く前にnpm run test:scripts（またはnpx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/package-scripts.test.js）でローカルに検証してください。ドキュメントとワークフローに矛盾がある場合は、ワークフローを信頼し、同じ変更でこのページを更新してください。

変数

リトライ回数

QWEN_CI_VITEST_RETRYおよびQWEN_RELEASE_VITEST_RETRYは、メインCIテストステップ（各ワークスペースのtest:ci。このステップは2つの同時レーンで実行され、npm run test:scripts:unitも含む）とリリースレーン（npm run test:release:workspaces）で、それぞれ--retry=<n>としてVitestに渡されます。2つのレーンは独立して調整できるように、別々の変数を持っています。

Vitestは失敗したテストを同じ実行内で再実行します。これは断続的な競合に役立つことがありますが、リトライバジェット内で回復した失敗はチェックをグリーンにし、フレーキー再実行トラッカーには失敗として記録されません。フレーキーなスイートをリトライで覆い隠すのではなく、バジェットを控えめに保ってください。どちらの変数もリテラル値offを受け付けます。この場合、--retry=0を渡すのではなく--retryフラグ自体が省略されます（コマンドラインの--retry=0はワークスペース独自のVitest設定よりも優先され、意図的なリトライポリシーを無効にしてしまうためです）。

ワークスペーステストのタイムアウト

QWEN_RELEASE_WORKSPACE_TIMEOUT_MINUTESは、リリースパイプラインの3つのworkspace_testsシャードそれぞれのジョブレベルのtimeout-minutesを設定します。タイムアウトはスイート自体ではなく予約済みホストの混雑度によってサイズが決められるため、テストの退行を想定するのではなく、ホストが競合している場合はこれを上げてください。

セルフホストランナーでのVitestワーカーキャップ

QWEN_CI_VITEST_MAX_WORKERSは、以下にリストされたステップ（VITEST_MAX_THREADS / VITEST_MAX_FORKS、対応する最小値は1に強制）におけるVitestプロセスを、名前がecs-qwen-で始まる予約済みセルフホストランナー上でキャップします。この変数はメインCIワークスペーステストステップとリリースのworkspace_testsおよびquality_scriptsステップでのみエクスポートされます。CIおよびリリースワークフローで同じ予約済みプールに到達するVitestを実行する他の統合テストはこれを消費せず、独自のVitest制限を使用します。WebシェルE2EスモークはARM64プールで独自の2つのPlaywrightワーカーで実行されるため、このキャップは適用されません。GitHubホストランナーではこの変数は無視され、Vitestは独自のデフォルトを使用します。

各Vitest実行はキャップを個別に適用します。メインCIワークスペーステストステップは2つのレーンを同時に実行します（.github/scripts/ci/run-unit-test-lanes.sh）。メインレーンはCLIとコアのスイートをキャップで実行し、サイドレーンは他のワークスペースのスイートとnpm run test:scripts:unitをキャップの半分（最低1）で実行するため、ピーク時にはキャップとその半分を合わせた数になります。GitHubホストランナーでは、サイドレーンのVitest実行は2ワーカーを使用します。

このステップは2つのシャード（Linux unit tests (shard N/2)）で実行され、それぞれのVitest実行に--shard=N/2を渡します。シャードもそれぞれキャップを適用するため、プールでは最大2つのこのようなステップが同時に実行されます。これらはprepareビルドなしでインストールし、test_buildが一度にビルドしたツリーを展開します。Test (ubuntu-latest, Node 22.x)はビルドとすべてのシャードがパスしたときにのみパスします。

test_buildが唯一ビルドを行うジョブです。これはscripts/ci-build-cache.mjsを通じてビルドします。プルリクエストはベースコミットのmainプッシュが保存したビルドを復元し（key --at <base>）、最新のキャッシュされたビルドにフォールバックし、入力が変更されたワークスペースのみを再ビルドします。ワークスペースの追跡ファイル（テストを除く）、ルートファイル、scripts/tests/以外のpatches/とscripts/、および依存するワークスペースです。mainへのプッシュは常にゼロからビルドし、そのビルドを保存します。キャッシュキーにはCPUアーキテクチャが含まれません。x64ラベルのプールにはARM64ホストが含まれており、アーキテクチャ固有の唯一の出力であるバンドルのopentuiネイティブライブラリは、復元と展開のたびにホスト用に再コピーされます（ci-build-cache.mjs host-assets）。

ユニットテストシャード、2つのIntegration Tests (no-AK, shard N/2)シャード、および2つのWebシェルスモークシャードはすべてその1つのツリーを展開します。test_buildはそれを読み取るチェック（サーブのファストパスバンドルクロージャー、コアのサブパスエクスポート、および設定スキーマの鮮度チェック。これらはLint & Staticが以前ビルドしていたもの）も実行します。Integration Tests (no-AK, No Sandbox)はビルドとすべての統合シャードがパスしたときにのみパスします。ドラフトプルリクエストは統合シャードとブラウザスモークをスキップし、レビュー準備完了にマークするとそれらを含む実行が開始されます。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 lintレーンを制御）とQWEN_RELEASE_BUILD_TIMEOUT_MINUTES（デフォルト45、quality_buildパッケージングレーンを制御）も公開しています。これらはテスト実行ではなく静的リンティングとアーティファクトビルドを制御するため、このページのテスト実行スコープの外にあります。