Ce tutoriel explique comment optimiser les pipelines CI/CD dans GitHub Actions en utilisant des matrices dynamiques, une technique permettant de réduire le temps et les ressources en ne reconstruisant que les composants réellement modifiés. L’auteur illustre cette approche à travers un projet démonstratif : un monorépôt hébergeant plusieurs microservices pour un raccourcisseur d’URL, structuré autour d’un API Gateway (Go), d’un service de création de liens (Go + Redis), d’un service de redirection avec analytique (Go + Redis + Kafka), d’un service d’analytique (Go + MongoDB + Kafka) et d’un frontend statique (HTML + Nginx). Chaque service possède son propre Dockerfile, et un docker-compose.yml simplifie le déploiement local.
L’innovation réside dans la détection automatique des modifications pour adapter la matrice de build. Contrairement aux matrices statiques (ex : builds multi-OS), cette méthode génère dynamiquement la liste des services à reconstruire en fonction des fichiers modifiés dans une Pull Request. Le workflow build-pr.yml se décompose en deux étapes clés : d’abord, un job changed-services identifie les répertoires modifiés via l’action tj-actions/changed-files, en ignorant les fichiers non pertinents (documentation, scripts). Un script analyse ensuite ces changements :
Si le dossier pkg/ (bibliothèques partagées) est modifié, tous les services Go (repérables par leur go.mod) sont reconstruits.
Sinon, seuls les services dont le répertoire contient un Dockerfile et a été modifié sont ciblés.
La matrice résultante est transmise au job suivant sous forme de sortie JSON.
Le second job, build, utilise cette matrice pour lancer des builds parallèles (avec strategy.matrix) des services concernés. Chaque build configure Docker Buildx, se connecte au GitHub Container Registry (GHCR), et génère des images multi-architectures (amd64/arm64) avec des tags spécifiques au PR (ex : pr-123, pr-123-sha123abc). Les images sont poussées vers GHCR, et un commentaire est automatiquement ajouté à la PR avec les détails des images construites et la commande docker pull correspondante. L’utilisation de caches (gha) accélère les builds ultérieurs.
Les avantages de cette approche sont multiples : économie de ressources (pas de rebuilds inutiles), scalabilité (ajout d’un nouveau service ne nécessite aucune modification du workflow), et transparence (feedback direct dans la PR). L’auteur propose en exercice d’affiner le système pour ne reconstruire que les services dépendant effectivement des modifications dans pkg/, plutôt que tous les services Go. Le dépôt exemple (url-shortener-demo) et les workflows associés sont disponibles pour expérimentation, tandis que des ressources complémentaires sur DevOps sont partagées via le canal Telegram de l’auteur.