Johan LEROY
0284cc0cd8
- ADR 0014 : un pipeline CI unique, « CI ok » seul check à exiger, déploiement du commit testé. - ADR 0015 : e2e et charge contre la stack Compose déployée, hypothèses et seuils de k6. - ADR 0016 : supervision en profil Compose, active en prod, rôle en lecture seule. - Nouvelle vue 60-observabilite.md ; 00-vue-ensemble, 10-infra, 20-backend et 50-cicd mis à jour (monitoring passé à Fait, nouveau graphe de CI, gates, ports). - README racine et guide de tests du frontend : où sont l'e2e, la charge et la supervision.
76 lines
5.0 KiB
Markdown
76 lines
5.0 KiB
Markdown
# 0014 - Un pipeline CI unique appelle les workflows de composant et conditionne le déploiement
|
|
|
|
- Statut : accepté
|
|
- Date : 2026-09-23
|
|
- Complète : [0009](0009-deux-environnements-compose-sur-la-vm-eni.md), qui reste en vigueur
|
|
|
|
## Contexte
|
|
|
|
Au 22/09, huit workflows se déclenchaient chacun de leur côté, et l'audit y a relevé :
|
|
|
|
- **Double exécution.** Chaque workflow partait sur `push` (toutes branches) **et** sur
|
|
`pull_request`. Un commit poussé sur une branche de PR jouait donc toute la CI deux fois,
|
|
à la même minute (constaté dans l'historique des runs de `test/integration-api-db-ml`).
|
|
- **Sonar refaisait tout.** `sonarqube.yml` reconstruisait le frontend et retestait frontend,
|
|
backend et ML pour produire ses rapports de couverture, en double exact de `frontend.yml`,
|
|
`backend.yml` et `ml.yml`. Son test backend tournait sans `uv sync`. Il n'avait ni
|
|
`permissions` ni `concurrency`.
|
|
- **Déploiement non conditionné.** `deploy.yml` partait à chaque push sur `dev` ou `main`,
|
|
que la CI du commit soit verte ou non, et déployait la pointe de branche du moment plutôt
|
|
que le commit poussé.
|
|
- **Erreurs silencieuses et hygiène.**
|
|
- `npm test --watch=false --code-coverage` : npm garde ces options pour lui, `ng test` ne
|
|
les reçoit jamais, et la CI ne tenait que par les réglages d'`angular.json`.
|
|
- `uv sync --frozen` ne vérifie pas que `uv.lock` suit `pyproject.toml`.
|
|
- Plusieurs actions tierces étaient épinglées par tag, contrairement à la règle Sonar
|
|
`githubactions:S7637`.
|
|
- Aucun job n'avait de `timeout-minutes` (360 minutes par défaut).
|
|
|
|
## Décision
|
|
|
|
**`ci.yml` est le seul workflow déclenché par `pull_request` et par les push sur `dev` et
|
|
`main`.** Les workflows de composant (`backend`, `frontend`, `ml`, `airflow`, `infra`, `e2e`)
|
|
passent en `workflow_call` et n'ont plus de déclencheur propre.
|
|
|
|
1. **`changes`.** Un job initial calcule, par `dorny/paths-filter` épinglé sur un SHA, les
|
|
composants touchés par la PR, et chaque composant n'est appelé que si son filtre vaut vrai.
|
|
Sur un push vers `dev` ou `main`, tous les filtres valent vrai : l'analyse Sonar reste
|
|
complète sur les branches longues, et paths-filter ne compare pas à la base de fusion avec
|
|
`main`, qui a 80 commits de retard.
|
|
2. **`sonar`.** Il ne reconstruit ni ne reteste plus rien : il télécharge, dans le même run, les
|
|
couvertures versées par les jobs `verification` des composants.
|
|
3. **`CI ok`.** Le job agrège le résultat de tous les autres. Il tourne toujours (`if:
|
|
always()`) et échoue dès qu'un job est en `failure` ou `cancelled`. **C'est le seul check à
|
|
exiger dans les règles de branche** : un composant sauté par son filtre ne publie aucun check
|
|
interne, qui resterait « en attente » s'il était exigé.
|
|
4. **`deploy`.** Il appelle `deploy.yml`, sur les seuls push, et seulement si `CI ok` a réussi.
|
|
`deploy.yml` aligne le dossier de l'environnement sur `GITHUB_SHA`, le commit testé.
|
|
|
|
`deploy.yml` n'a toujours **aucun déclencheur `pull_request`** : il n'accepte que
|
|
`workflow_call` et `workflow_dispatch`, dans l'esprit de l'ADR 0009.
|
|
|
|
## Alternatives écartées
|
|
|
|
| Écartée | Raison |
|
|
|---|---|
|
|
| Garder huit workflows et restreindre seulement `push` à `dev` et `main` | Supprime la double exécution, pas le doublon Sonar : il faudrait toujours rejouer les tests pour que Sonar ait ses couvertures, les artefacts ne passant pas d'un workflow à l'autre. Et rien n'empêche un déploiement rouge. |
|
|
| Déclencher le déploiement par `workflow_run` | `workflow_run` joue toujours le fichier de la branche par défaut, `main`, en retard de 80 commits : la recette ne se serait plus déployée avant la prochaine remontée vers `main`, sans erreur visible. |
|
|
| `alls-green` ou une action tierce d'agrégation | Dix lignes de shell sur `toJSON(needs.*.result)` font le même travail, sans dépendance de plus à épingler. |
|
|
| Cache de couches Docker (`bake-action`, `type=gha`) pour l'e2e | Quatre pièges (noms d'image, cibles Compose, buildx, `load`) pour deux à quatre minutes gagnées. Reporté après le rendu. |
|
|
|
|
## Conséquences
|
|
|
|
- Une PR ne joue que ce qu'elle touche. Une PR de documentation ne joue que `changes` et
|
|
`CI ok`.
|
|
- Les checks s'appellent désormais « Backend / Lint, typage et tests », etc. Au 23/09, ni `dev`
|
|
ni `main` n'ont de règle de protection : à la première, exiger **« CI ok »** et rien d'autre.
|
|
- Modifier `ci.yml` rejoue toute la CI sur la PR (filtre `ci`).
|
|
- Le job `deploy` reste en file tant que le runner `eni-g3` n'est pas enregistré sur la VM,
|
|
comme avant. Le groupe de concurrence par SHA des push l'empêche de bloquer les runs suivants.
|
|
- La sécurité du runner auto-hébergé ne repose pas sur l'absence de `pull_request` dans
|
|
`deploy.yml`. Une PR de fork peut ajouter son propre workflow. Ce qui protège le runner :
|
|
- l'approbation obligatoire des workflows de tous les contributeurs externes ;
|
|
- les règles de branche des environnements `rec` (`dev`) et `prod` (`main` et un relecteur).
|
|
|
|
Ces deux réglages restent à poser par l'administratrice du dépôt.
|