Aller au contenu principal

V0.7.1 — Intégration continue

Publiée le 18/10/2026.

Documentation fonctionnelle

Ce que change la version pour les collaborateurs

Pourquoi​

Les tests (/t) et la stack Docker ne tournaient que sur la machine du développeur. Une PR pouvait être fusionnée dans main alors que la suite était rouge.

Ce qu'on peut faire maintenant​

  • Une PR vers main (y compris brouillon) lance le check ArgOS tests ; on voit le résultat sur la PR et dans Actions. PR #106 brouillon Checks PR — ArgOS tests ArgOS tests rouge
  • main est protégé : tant que ArgOS tests n’est pas vert, la PR ne se fusionne pas (mergeable_state: blocked). Preuves protection + merge bloqué
  • La doc (README Développer + checks requis sur main) dit d’ajouter toute nouvelle CI à la liste des checks requis sur main.
  • Un script du dépôt (scripts/lancer-les-tests.sh) rejoue le même travail hors Actions (stack Docker + racines test-roots).

Documentation technique

Spec versionnée : docs/specs/v0.7.1-integration-continue.md

Issue parente : #102

V0.7.1 — Intégration continue

Problem Statement​

Les tests (/t) et la stack Docker ne tournent que sur la machine du développeur. Une PR peut être fusionnée dans main alors que la suite est rouge : on ne s'en aperçoit qu'après coup, localement. Il n'existe encore aucun workflow GitHub Actions qui lance les tests (seul deploy-docs.yml publie la documentation).

Solution​

Sur chaque pull request vers main (y compris les brouillons), un workflow GitHub Actions sur ubuntu-latest lance l'équivalent de /t -a : stack Docker avec simulation, puis la suite complète de chaque racine listée dans agents/roles.yml (test-roots).

La logique vit dans un script du dépôt (install des outils, .env éphémère avec le compte Administrateur d'exemple, Compose, pytest) ; le workflow ne fait que le checkout et l'appel au script. Un seul job séquentiel, échec dès qu'une racine est rouge, annulation du run précédent sur la même PR.

Le README (Développer) et une courte note sous agents/docs/ expliquent d'exiger ce check (et tout check CI ajouté plus tard) dans la protection de branche de main : tant qu'un check requis est rouge, la PR ne peut pas être fusionnée. La configuration Settings reste manuelle (pas d'API qui reconfigure le dépôt).

Pas de scanner Sonar dans Actions (Automatic Analysis + /qg local inchangés). Pas de cache d'artefacts dans cette version.

User Stories​

  1. En tant que mainteneur, je veux que chaque PR vers main lance automatiquement la suite de tests complète (stack Docker comprise), pour savoir avant le merge si le SHA est vert.
  2. En tant que mainteneur, je veux qu'une PR dont le check de tests est rouge ne puisse pas être fusionnée (checks requis sur main), pour protéger main.
  3. En tant que mainteneur, je veux que les PR en brouillon déclenchent aussi ce workflow, pour détecter une régression tôt.
  4. En tant que développeur, je veux un script rejouable hors Actions qui fait le même travail que la CI, pour reproduire un échec localement comme en CI.
  5. En tant que développeur / agent, je veux que le script lise les racines dans agents/roles.yml, pour qu'une racine ajoutée à /t soit couverte en CI sans oublier le script.
  6. En tant qu'adopteur du dépôt, je veux lire dans le README et dans agents/docs/ comment exiger le check ArgOS (et les CI futures) sur main, pour poser la règle « pas de merge tant que les checks requis ne sont pas verts ».
  7. En tant que mainteneur, je veux qu'un nouveau push sur une PR annule le run de tests en cours, pour ne pas brûler des minutes sur un SHA déjà dépassé.

Implementation Decisions​

  • Déclencheur : pull_request vers main seulement (pas de push sur main pour ce job).
  • Runner : ubuntu-latest ; build depuis le clone de la PR (docker compose + --build), pas d'images du registre (0.7.2).
  • Script dédié sous scripts/ (nom libre à l'implémentation) ; workflow YAML mince sous .github/workflows/.
  • Racines : lecture de roles.test-roots.paths dans agents/roles.yml ; pytest via .venv / uv comme en local ; Chromium Playwright installé pour tests/web/.
  • .env : créé sur le runner à partir de .env.example + compte d'exemple README (administrateur / phrase de test) ; aucun secret GitHub requis pour 0.7.1.
  • Un job, séquentiel, fail-fast ; concurrency avec cancel-in-progress par PR.
  • Doc : section README Développer + courte note agents/docs/ (checks requis, ajouter toute CI future à la liste).
  • Pas d'ADR ; pas de cache uv/Playwright/Docker dans 0.7.1 ; pas de scanner Sonar CI ; bug #95 hors périmètre.

Testing Decisions​

  • Preuve automatique : le workflow + le script existent ; la PR de version exerce le job dès que le workflow est sur la branche.
  • Tests scripts : le script peut être exercé hors Actions si pertinent (tests/scripts/) ; priorité = job vert sur runner GitHub.
  • Tests humains : activer la protection de main (exiger le check du workflow) ; ouvrir ou utiliser une PR volontairement rouge et constater que le merge est refusé ; documenter le geste pour un futur lecteur.

Out of Scope​

  • Publication des images au registre GitHub / livraison continue (0.7.2).
  • Scanner Sonar dans Actions ; changement du modèle Automatic Analysis + /qg.
  • Caches GitHub Actions (uv, Playwright, couches Docker).
  • Runners self-hosted.
  • Configuration automatique de la branch protection via l'API GitHub.
  • Jobs parallèles par racine de tests.
  • Correction du bug #95 (Caméras de dev qui polluent la suite locale).
  • Bugs #86.

Changements apportés aux versions antérieures​

Aucun.

Further Notes​

  • Le nom exact du workflow / du check affiché dans GitHub doit être repris tel quel dans le README et agents/docs/, pour que Settings → require status checks soit sans ambiguïté.
  • Sonar et le quality gate (/qg, /cqg) restent hors de ce workflow ; finaliser-la-version continue de lire le gate une fois avant le tag.