Skip to main content
Chaque dépôt applicatif chez Kaeyros Analytics dispose d’un workflow GitHub Actions qui automatise la construction, les tests et la publication des images Docker. Le fichier .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.
La pipeline échoue immédiatement si Semgrep détecte une vulnérabilité de niveau ERROR ou si gitleaks trouve un secret exposé. Aucune image n’est publiée en cas d’échec de la phase security.

Adaptations par langage

Utilisez actions/setup-node@v4 avec cache npm. Les étapes de test utilisent npm test ou npm run test:coverage.
Pour toute modification du workflow standard, ouvrez une PR sur le dépôt de référence et demandez une review à l’équipe DevOps.