4.5CI : construire et pousser une image à chaque commit
L'essentiel en 30 secondes
- La CI est la seule usine à images : à chaque push sur main, elle récupère le code, se connecte au registre et construit + pousse — fini les builds « à la main sur le portable ».
- On tague SHA + version : l'empreinte du commit pour la traçabilité exacte, la version pour la lisibilité — la production déploie le SHA ou la version, jamais un alias mouvant.
- Réflexe d'Idir : cache activé pour des builds rapides, identifiants en secrets du dépôt, jamais dans le fichier de workflow.
Mini-cas filé — Idir branche l'usine à images de son équipe
Idir, devops junior à Alger, en a assez des images construites à la main dont personne ne connaît le contenu : il écrit un workflow qui, à chaque push sur main, se connecte à GHCR via le token du dépôt, construit avec cache et pousse l'image taguée avec l'empreinte du commit. L'équipe tire ensuite l'image du commit exact. Dernier jalon du fil rouge : chaque commit donne une image déployable et traçable, sans intervention manuelle.
Dernier cas du fil rouge 4.1-4.5 — Idir boucle son niveau : publier, fiabiliser, exposer, sauvegarder, automatiser.
1. Le pipeline minimal qui change tout
À chaque push sur main : récupération du code, connexion au registre (secret du dépôt), build + push tagués. Plus aucun build « à la main sur le portable » : la CI est la seule usine à images — comme l'usine d'Idir, chaque image a une origine connue.
Et on ne versionne que le vert : un job de tests avant le build évite de pousser des images cassées.
2. Taguer intelligemment en CI
On pousse l'empreinte du commit (traçabilité exacte : cette image = ce code) + la version (lisible, sur tag git) + un alias de branche en développement. En production on déploie l'empreinte ou la version, jamais un alias mouvant — Idir peut ainsi redéployer exactement le commit validé.
Ne pousser que l'alias mouvant, c'est redevenir intraçable : le pipeline doit toujours produire au moins un tag exact.
3. Cache et secrets : les deux réglages
Le cache réutilise les couches entre les runs et divise les temps de build. Les identifiants vivent en secrets du dépôt, jamais dans le fichier de workflow. Un pipeline qui affiche un secret dans les logs est un pipeline à corriger d'urgence — puis on révoque le secret exposé.
Permission minimale : le job ne reçoit que les droits dont il a besoin (écriture des paquets, rien de plus).
🔎 Exemple concret — 🔎 Exemple concret — Workflow GitHub Actions minimal
L'usine d'Idir : connexion par token du dépôt, build + push de l'empreinte.
name: image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
permissions:
packages: write
steps:
- uses: actions/checkout@v4
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
push: true
tags: ghcr.io/monequipe/app:${{ github.sha }}Lecture : connexion par token automatique, build + push de l'empreinte du commit.
Leçon : chaque commit donne une image déployable et traçable.
Vocabulaire de la section
- Pipeline
- La CHAÎNE automatique : test, puis build, puis push (puis déploiement).
Exemple simple : À chaque push, l'usine d'Idir teste, construit et pousse sans intervention.
Ce que ce n'est pas : des commandes tapées à la main sur un portable.
Réflexe : répéter un build à la main : l'écrire en pipeline.
- SHA
- L'EMPREINTE du commit : tag de traçabilité exacte (cette image = ce code).
Exemple simple : Idir redéploie exactement l'image du commit validé.
Ce que ce n'est pas : un alias mouvant qui change de contenu.
Réflexe : production : déployer une empreinte ou une version, jamais un alias.
- Secret CI
- Variable SENSIBLE stockée dans le dépôt, masquée des logs et jamais écrite dans le fichier.
Exemple simple : Le token de registre d'Idir vit en secret, pas dans le workflow.
Ce que ce n'est pas : un mot de passe collé en clair dans le fichier.
Réflexe : identifiant en CI : secret du dépôt, toujours.
- Usine unique
- La CI SEULE produit les images déployées : origine connue, builds reproductibles.
Exemple simple : L'équipe d'Idir ne déploie que des images sorties du pipeline.
Ce que ce n'est pas : des images poussées « vite fait » depuis un portable.
Réflexe : image dont on ignore l'origine : interdire, passer par la CI.
En pratique — En pratique — Votre première usine
- Créez le workflow ci-dessus dans .github/workflows/image.yml.
- Poussez sur main et suivez le run (vert ?).
- Vérifiez l'image taguée dans les paquets du registre.
- Tirez-la et lancez-la : le commit tourne.
Script prêt à dire — annoncer l'usine à l'équipe (30 s)
« C'est Idir : à chaque push sur main, la CI teste, construit avec cache et pousse l'image taguée avec l'empreinte du commit. Le token reste en secret du dépôt, jamais dans le fichier. On déploie l'empreinte exacte : fini les images dont personne ne connaît le contenu. »
À dire en revue : montrez le run vert et l'image du commit dans le registre.
Modèle copier-coller — workflow build + push (générique, valide)
name: image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
steps:
- uses: actions/checkout@v4
- uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- uses: docker/build-push-action@v6
with:
context: .
push: true
tags: ghcr.io/monequipe/app:${{ github.sha }}Version lisible en plus
Comme Idir : empreinte du commit + version sur tag git — traçabilité exacte et lecture humaine.
Builds trop lents
Activer le cache entre runs : les couches inchangées sont réutilisées, les builds sont divisés.
Image cassée poussée
Ajouter le job de tests avant le build : on ne versionne que le vert.
Secret affiché en log
Corriger d'urgence, retirer tout affichage de débogage, puis révoquer et remplacer le secret exposé.
✓ Bonnes pratiques
- Tag exact systématique + version sur tag git.
- Activer le cache des builds.
- Secrets en secrets dépôt, jamais en clair.
✗ Pièges fréquents
- Builder en local puis pousser « vite fait ».
- Ne pousser que l'alias mouvant (intraçable).
- Afficher un secret en echo de débogage.
Points clés à retenir
- La CI build + pousse, pas le portable.
- Empreinte = traçabilité, version = lisibilité.
- Cache = builds rapides.
- Secrets hors workflow, toujours.
Défi 48h — appliquez demain
Sur un vrai dépôt : créez le workflow, poussez sur main, vérifiez l'image taguée dans le registre puis lancez-la.
- Je sais écrire un workflow build + push déclenché sur main.
- Je sais taguer empreinte + version et déployer l'exact.
- Je sais gérer secrets, cache et permissions minimales.
Questions fréquentes
Faut-il tester avant de builder ?
Oui : un job de tests avant le build évite de pousser des images cassées. On ne versionne que le vert.
Et le déploiement auto ?
Étape suivante : d'abord une usine fiable (build + push traçables), ensuite la livraison. Sans usine fiable, l'automatisation du déploiement ne fait qu'accélérer les erreurs.
En CI, quel tag déployer en production ?