eqs-workflows

Les workflows Forgejo réutilisables de la flotte EQS. Un dépôt n'a qu'un ci.yml de trente lignes qui les appelle par uses:. Une correction de workflow est une bascule de version, pas N pull requests.

Cahier des charges : eqs-platform/depots-lies/eqs-workflows/CAHIER-DES-CHARGES.md. Il n'est pas copié ici : un cahier en deux exemplaires devient deux cahiers.

Le problème

ATLAS a un ci.yml de 321 lignes, Topologie et MCP aussi, tous différents, aucun n'appelant un workflow central. Et pendant des mois aucun ne tournait : le runner n'enregistrait pas les labels demandés. Une CI « informative » qui ne s'exécute pas est verte pour toujours.

Ce qu'un satellite écrit

Un appel, à pipeline.yml : modèle complet dans examples/ci.yml.

# .forgejo/workflows/ci.yml
# La porte est le pre-push : un push sur main part en production par webhook.
# Cette CI constate ; elle ne bloque pas (D-013). Sauf la sécurité : rouge = défaut réel.
name: ci
on: { push: { branches: [main] }, pull_request: {} }
concurrency: { group: "ci-${{ github.ref }}", cancel-in-progress: true }
jobs:
  pipeline:
    uses: Infrastructure/eqs-workflows/.forgejo/workflows/pipeline.yml@v1
    with: { start: start, base-url: "http://127.0.0.1:3000", sante: /health }
    secrets: { topologie-token: "${{ secrets.TOPOLOGIE_TOKEN }}" }

La phrase en tête est la seule qu'on autorise à copier, parce qu'elle doit être lue là où quelqu'un se demande pourquoi la CI est verte alors que la production est cassée.

Pourquoi trois jobs, et pas neuf

Le runner ne fait qu'un job à la fois pour toute la forge (D-066). Des jobs séparés ne tournent pas en parallèle : ils se paient en série, chacun avec son conteneur, son checkout, sa restauration de cache et son pnpm install. Mesuré sur ATLAS (run 27) : cinq installations et trois next build de 2 min 10 pour un commit, et un audit envoyé à Topologie avant le verdict de l'intégration et du fuzzing.

Job	Ce qu'il fait	Ce qu'il ne refait pas
porte	install, eqs check (séquentiel : 4 Go), contrat à jour (build seulement si l'export lit un dist/)	—
securite	gitleaks (historique complet), trivy, semgrep, actionlint + shellcheck	aucun install
application	install, un build, intégration (vraie base), fuzzing sur une base neuve, audit	le build de l'intégration et du fuzzing

L'audit envoyé à Topologie voit la durée de la porte (artefact check-duree) et la conformité jouée par l'intégration, mesurées dans le même run.

Les caches : le store pnpm vit dans .git/pnpm-store (le dépôt est le seul montage du job où pnpm peut lier au lieu de copier), et le cache de compilation de Next survit d'un run à l'autre. Une entrée par lockfile pour chacun : le serveur de cache du runner ne purge qu'à son démarrage.

Les workflows par étage (check, security, integration, contract, audit) restent appelables pour les dépôts qui ne sont pas encore passés au pipeline. mutation.yml se lance à la main (D-083), smoke.yml par sa propre planification.

Versionnement

Tags v1, v1.x. Un dépôt suit @v1 et reçoit les corrections sans rien faire. Un changement incompatible est v2, propagé par une PR sur chaque dépôt.

Préalables

Préalable	Décision	État
Actions activé sur l'instance	D-034	oui, depuis le 2026-09-07 (Forgejo 15.0.7)
Labels node-22 et alpine sur le runner	D-014	oui
Aucun docker build en CI — Coolify construit	D-015	tenu : aucun workflow ne touche au daemon
Jeton de lecture du registre npm pour pnpm install	D-032, D-033	secret FORGEJO_NPM_TOKEN

Une porte qui ment

Chaque workflow est livré avec un dépôt fautif contre lequel il doit échouer (verify/). Un workflow sans cas négatif n'est pas fusionné. C'est la règle du cadre de tests (§1, principe 6) et du harnais forgejo-runner/scripts/verify.sh.