Skip to main content

​
Un seul check bloquant

CI Status — le job agrégateur de ci.yml — est le seul contexte requis par la protection de branche main. Tous les autres workflows rendent la PR rouge sans empêcher le merge : un bouton vert ne veut donc pas dire « tout est passé ».
Pourquoi : chaque workflow annexe est filtré par paths au niveau du trigger, donc il ne démarre pas du tout sur une PR hors de son périmètre. Un contexte requis qui ne démarre jamais laisse la PR en attente indéfiniment. Rendre l’un d’eux bloquant impose de descendre son filtre du trigger vers une condition de job, pour que le workflow démarre toujours et qu’un job de gate rende le verdict.

​
Les workflows

pr-openapi ne commite pas la spec régénérée : un commit de bot relancerait toute la CI requise pour un JSON généré. Lance yarn docs:openapi dans apps/api et commite le résultat.

​
Turbo --affected

ci.yml fixe explicitement TURBO_SCM_BASE / TURBO_SCM_HEAD (PR, merge queue ou push) : dans un checkout détaché, Turbo ne résout pas le ref main et retomberait sur « tout reconstruire ». Le checkout utilise fetch-depth: 0 pour la même raison.

​
Runners auto-hébergés

Les jobs tournent sur un serveur dédié, répartis par profil de ressources : Le cache Yarn et le cache Turbo sont persistés sur le NVMe de l’hôte et partagés entre ci-api-integration et le gate qa-api du déploiement : un merge dont les sources API sont identiques à celles de la PR relit le résultat au lieu de rejouer la suite. Une suite en échec n’est jamais mise en cache.
Le code d’une PR s’exécute sur l’hôte qui construit les images de déploiement. Risque résiduel assumé et connu : un postinstall npm malveillant (via un bump Dependabot) s’exécuterait sur cet hôte.

​
Normes de sécurité

​
E2E Playwright

E2E (kare) ne démarre que si les variables de repo E2E_KARE=true et E2E_API_URL=https://api.rs.staging.kare-app.fr sont posées, avec E2E_EMAIL / E2E_PASSWORD en secrets. Sinon le job est skipped et CI Status reste vert.