Variables de CI et de release

Plusieurs knobs des pipelines de CI et de release sont exposés en tant que variables de dépôt GitHub Actions (le contexte vars.*) afin que les opérateurs puissent les ajuster sans ouvrir de pull request. Cette page liste les variables qui affectent l’exécution des tests dans .github/workflows/ci.yml et .github/workflows/release.yml, ainsi que leurs valeurs par défaut et leur champ d’application.

Définir une variable

Les mainteneurs du dépôt définissent ces variables sous Settings → Secrets and variables → Actions → Variables. Une variable non définie (ou vide) utilise le fallback dans l’expression du workflow. La limite de workers s’applique uniquement sur les runners réservés, même lorsque sa variable est définie.

Les fichiers de workflow sont la source de vérité pour ces leviers, et les suites de tests épinglent les expressions du workflow octet pour octet : scripts/tests/package-scripts.test.js épingle l’expression partagée de limite de workers dans release.yml (QWEN_CI_VITEST_MAX_WORKERS avec la garde ecs-qwen-), scripts/tests/no-ak-integration-ci.test.js épingle l’expression de limite de workers dans ci.yml, et scripts/tests/release-workflow.test.js épingle les expressions de retry et de timeout de test de workspace de release.yml. scripts/tests/package-scripts.test.js vérifie également les valeurs par défaut documentées et les emplacements de workflow par rapport aux deux workflows. scripts/tests/package-scripts.test.js vérifie également les valeurs par défaut documentées et les emplacements de workflow par rapport aux deux workflows. Comme cette garde s’exécute sur la lane CI complète (test:scripts) plutôt que sur les vérifications docs uniquement, vérifiez les modifications limitées à cette page en local avant d’ouvrir une pull request avec npm run test:scripts (ou npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/package-scripts.test.js). Si les docs et les workflows divergent un jour, faites confiance aux workflows et mettez à jour cette page dans le même changement.

Variables

Nombre de retries

QWEN_CI_VITEST_RETRY et QWEN_RELEASE_VITEST_RETRY sont passés à Vitest sous la forme --retry=<n> dans l’étape de test CI principale (test:ci de chaque workspace, que cette étape exécute dans deux lanes concurrentes, et npm run test:scripts:unit) et sur la lane de release (npm run test:release:workspaces) respectivement. Les deux lanes ont des variables séparées afin de pouvoir être ajustées indépendamment.

Vitest relance les tests en échec au sein du même run. Cela peut aider en cas de contentions intermittentes, mais un échec qui récupère dans le budget de retries valide le check et n’est pas enregistré comme un échec par le tracker de flaky-rerun. Gardez le budget modeste au lieu d’utiliser les retries pour masquer une suite instable. Les deux variables acceptent également la valeur littérale off, qui omet entièrement le flag --retry au lieu de passer --retry=0 (un --retry=0 en ligne de commande prend le pas sur la config Vitest du workspace et désactiverait une politique de retry délibérée).

Timeout de test workspace

QWEN_RELEASE_WORKSPACE_TIMEOUT_MINUTES définit le timeout-minutes au niveau du job pour chacun des trois shards workspace_tests dans le pipeline de release. Le timeout est dimensionné en fonction de la charge de l’hôte réservé plutôt que par la suite elle-même, augmentez-le donc lorsque l’hôte est en contention plutôt que de supposer une régression de test.

Limite de workers Vitest sur les runners auto-hébergés

QWEN_CI_VITEST_MAX_WORKERS limite les processus Vitest dans les étapes listées ci-dessous (VITEST_MAX_THREADS / VITEST_MAX_FORKS, avec le minimum correspondant forcé à 1) sur les runners auto-hébergés réservés dont le nom commence par ecs-qwen-. La variable est exportée uniquement par l’étape de test workspace CI principale et les étapes workspace_tests et quality_scripts de release ; les autres tests d’intégration exécutant Vitest qui arrivent dans le même pool réservé dans les workflows CI et release ne la consomment pas ; ils utilisent leurs propres limites Vitest. Le smoke E2E web-shell s’exécute sur le pool ARM64 avec ses deux workers Playwright propres, donc la limite ne s’applique pas à lui. Sur les runners hébergés par GitHub, la variable est ignorée et Vitest utilise ses propres valeurs par défaut.

Chaque exécution de Vitest applique la limite individuellement. L’étape de test workspace CI principale exécute deux lanes en même temps (.github/scripts/ci/run-unit-test-lanes.sh) : la limite borne chaque exécution Vitest dans la lane principale, et la suite web-shell dans la lane secondaire s’exécute avec la moitié de la limite, au minimum 1, donc à son pic l’étape exécute la limite plus cette moitié. Sur les runners hébergés par GitHub, la variable est ignorée et Vitest utilise ses propres valeurs par défaut.

Chaque exécution de Vitest applique la limite individuellement. L’étape de test workspace CI principale exécute deux lanes en même temps (.github/scripts/ci/run-unit-test-lanes.sh) : la lane principale exécute les suites CLI et core à la limite, et la lane secondaire exécute les suites des autres workspaces et npm run test:scripts:unit à la moitié de la limite, au minimum 1, donc à son pic l’étape exécute la limite plus cette moitié. Sur les runners hébergés par GitHub, les exécutions Vitest de la lane secondaire utilisent 2 workers.

L’étape s’exécute en deux shards (Linux unit tests (shard N/2)), chacun passant --shard=N/2 à chacune de ces exécutions Vitest. Les shards appliquent aussi la limite individuellement, donc le pool voit jusqu’à deux telles étapes en même temps. Ils s’installent sans le build prepare et dépaquettent l’arborescence construite une seule fois par test_build. Test (ubuntu-latest, Node 22.x) passe uniquement quand le build et tous les shards passent.

test_build est le seul job qui construit. Il construit via scripts/ci-build-cache.mjs : une pull request restaure le build que le push main de son commit de base a sauvegardé (key --at <base>), avec un fallback vers le build caché le plus récent, et ne reconstruit que les workspaces dont les entrées ont changé : les fichiers suivis d’un workspace hors tests, les fichiers racine, patches/ et scripts/ hors scripts/tests/, et les workspaces dont il dépend. Un push sur main construit toujours from scratch et sauvegarde ce build. La clé de cache ne porte pas d’architecture CPU : le pool labellisé x64 inclut des hôtes ARM64, et la seule sortie spécifique à l’architecture, la bibliothèque native opentui du bundle, est recopiée pour l’hôte après chaque restauration et dépaquetage (ci-build-cache.mjs host-assets).

Les shards de tests unitaires, les deux shards Integration Tests (no-AK, shard N/2) et les deux shards de smoke web-shell dépaquettent tous cette arborescence unique. test_build exécute également les vérifications qui la lisent, le bundle serve fast-path, les exports de sous-chemin core et la vérification de fraîcheur du schéma de paramètres, que Lint & Static construisait auparavant. Integration Tests (no-AK, No Sandbox) passe uniquement quand le build et tous les shards d’intégration passent. Une pull request draft évite les shards d’intégration et le smoke navigateur ; la marquer prête pour review démarre l’exécution qui les inclut. Un changement limité à packages/managed-agent-server/ ou packages/sdk-java/ (sauf les fichiers lus par les suites TypeScript) est classifié comme java_only : Lint & Static exécute son payload plus les suites scripts/tests qui nomment ces arborescences, et les lanes de build et test TypeScript évitent.

Variables associées hors exécution de tests

Variables associées hors exécution de tests

release.yml expose également QWEN_RELEASE_STATIC_TIMEOUT_MINUTES (défaut 60, contrôlant la lane lint quality_static) et QWEN_RELEASE_BUILD_TIMEOUT_MINUTES (défaut 45, contrôlant la lane de packaging quality_build). Comme elles régissent le lint statique et la construction d’artifacts plutôt que l’exécution de tests, elles sont hors du champ d’exécution de tests de cette page.