Lab 09 — Publier dans le registry

Construire une image dans un job CI ne suffit pas. Si vous ne la poussez pas dans un registry, elle disparaît à la fin du job. Le résultat est perdu et votre équipe ne peut pas réutiliser l’image pour déployer. Ce lab vous apprend à publier proprement vos images dans GitLab Container Registry avec des tags exploitables.

Ce que vous allez apprendre

Utiliser $CI_REGISTRY_IMAGE et les identifiants CI injectés par GitLab
Publier une image avec un tag traçable ($CI_COMMIT_SHORT_SHA)
Maintenir un tag latest sans perdre la traçabilité
Vérifier la présence de l’image dans l’UI GitLab

Dans quel contexte ?

Un pipeline qui ne publie pas ses artefacts finaux est incomplet. En pratique, les équipes ont besoin d’une image versionnée pour :

déployer en staging puis production
rollback sur une version précise
reproduire un incident avec l’image exacte

Sans tag immuable, vous perdez la traçabilité. Sans docker login, le push échoue. Sans discipline de tag, vous déployez au hasard.

Prérequis

Lab 08 — Déclencher un pipeline terminé
Avoir lu Registries GitLab

Point de départ

Passez sur la branche du lab
Fenêtre de terminal
```
cd pipeline-craft
git checkout starter/lab-09
```
Vérifiez le job docker-build

Le job construit l’image mais la publication peut être incomplète ou mal taggée.

Le problème

Vous devez standardiser la publication :

authentification registry systématique
tag immuable pour chaque commit
tag latest pour l’image courante

L’objectif est de pouvoir dire précisément : “la version en prod correspond à ce commit”.

L’exercice

Étape 1 — Publier avec les variables GitLab

Configurez le script du job de build

docker-build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

Comprenez la logique de tag

Le tag SHA est immuable. Il permet un rollback propre. Le tag latest est pratique pour les environnements de test, mais ne doit pas être votre seule référence en production.

Étape 2 — Déclencher et vérifier

Commitez puis poussez

git add .gitlab-ci.yml
git commit -m "ci: publish image to gitlab container registry"
git push origin starter/lab-09

Ouvrez Packages & Registries > Container Registry

Vérifiez que les deux tags sont présents.
Notez le lien entre image et commit

Le tag SHA vous permet de retrouver la source exacte de l’image.

Étape 3 — Préparer la publication package (option)

Vérifiez que votre projet est compatible packaging
Préparez un job dédié pour un lab ultérieur

Ce lab se concentre sur le registry d’images. La publication package pourra être ajoutée ensuite avec twine.

Vérification

docker login passe sans erreur
Le push des deux tags réussit
Les tags sont visibles dans Container Registry
Vous pouvez relier un tag SHA à un commit Git

Pièges fréquents

Le tag latest seul est insuffisant pour investiguer un incident. Utilisez toujours un tag immuable en parallèle.

Un autre piège fréquent est de supposer que les credentials registry doivent être ajoutés à la main. Dans GitLab CI, ils sont déjà injectés via les variables prédéfinies si le registry est activé.

À retenir

Une image non poussée est perdue à la fin du job
CI_REGISTRY_* simplifie l’authentification sécurisée
Le duo SHA + latest couvre traçabilité et usage courant
La publication registry est une étape clé vers un déploiement fiable

Prochaines étapes

Lab 10 — Rapports qualité Rendre les résultats de tests visibles dans les Merge Requests

Guide : registries Approfondir Container Registry et Package Registry

Retour au Lab 08 Déclencheurs et pipeline source