.github/workflows/ci.yml est le contrat standard partagé par tous les services backend et frontend.
Structure du workflow type
Le workflow est déclenché sur chaque push et chaque pull request. Il s’adapte automatiquement à la branche cible pour produire le bon tag d’image..github/workflows/ci.yml
Étapes standard détaillées
1
Checkout du code
Récupération du code source avec
actions/checkout@v4 et historique complet pour les analyses de sécurité.2
Setup du runtime
Installation de Node.js 20 (ou Python 3.11 / Rust selon le projet) avec cache des dépendances.
3
Installation des dépendances
npm ci pour une installation reproductible et rapide, ou équivalent pip install / cargo build.4
Tests et couverture
Exécution des tests unitaires et génération du rapport de couverture. Échec de la pipeline si couverture < 70%.
5
SAST avec Semgrep
Analyse statique de sécurité avec les règles OWASP Top 10 et security-audit. Les findings bloquants arrêtent la pipeline.
6
Détection de secrets avec gitleaks
Scan du dépôt à la recherche de secrets exposés (clés API, tokens, mots de passe). Zero tolérance.
7
Build de l'image Docker
Construction multi-stage avec Buildx et cache GitHub Actions pour accélérer les builds successifs.
8
Push vers ghcr.io
Publication de l’image avec le tag approprié : SHA court pour
develop/staging, SemVer pour production.Stratégie de taggage des images
Les secrets utilisés par les workflows (GHCR_PAT, tokens d’accès) sont stockés dans GitHub Secrets au niveau de l’organisation ou du dépôt. Consultez la page dédiée aux secrets pour la procédure de rotation.
Adaptations par langage
- Node.js
- Python
- Rust
Utilisez
actions/setup-node@v4 avec cache npm. Les étapes de test utilisent npm test ou npm run test:coverage.