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

Quel lab commencer ?

Ce lab est la suite du Lab 08. Si vous savez déjà déclencher un pipeline et lire les variables CI, vous pouvez commencer directement via starter/lab-09.

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 — À vous de publier avec les variables GitLab

Configurez le job de build pour publier deux tags :
- un tag immuable basé sur le SHA
- un tag latest
Vérifiez l'authentification registry avec les variables CI prédéfinies.
Confirmez la logique de traçabilité : rollback possible avec le tag SHA.

👉 Vérifier votre solution (Étape 1)

1️⃣ Job `docker-build` avec double tag

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

2️⃣ Variables prédéfinies utilisées

Variable	Valeur exemple
`$CI_REGISTRY`	`registry.gitlab.com`
`$CI_REGISTRY_IMAGE`	`registry.gitlab.com/user/pipeline-craft`
`$CI_REGISTRY_USER`	`gitlab-ci-token`
`$CI_REGISTRY_PASSWORD`	(token de session CI, injecté automatiquement)
`$CI_COMMIT_SHORT_SHA`	`a1b2c3d4`

Le docker login avant docker push est obligatoire. GitLab injecte ces credentials automatiquement — pas besoin de les configurer manuellement.

Étape 2 — À vous de 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.

👉 Vérifier votre solution (Étape 2)

1️⃣ Vérifier dans Container Registry

Allez dans Packages & Registries > Container Registry
Vous devriez voir deux tags sur votre image :
- a1b2c3d4 (SHA court du commit)
- latest
Cliquez sur un tag pour voir les métadonnées

2️⃣ Relier commit et image

Le tag SHA vous permet de retrouver le contexte exact :

git show a1b2c3d4

En cas d'incident en production, vous pouvez déployer exactement l'image correspondant au commit connu comme stable.

Étape 3 — À vous de 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érifier votre solution (Étape 3)

1️⃣ Extension vers Package Registry (référence)

Dans solution/lab-09, le lab prépare un squelette minimal pour la publication package :

publish-package:
  stage: build
  image: python:3.12-slim
  script:
    - echo "Would publish package to GitLab Package Registry"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Ce lab se concentre sur le registry d'images. La publication package complète (build + upload) arrive dans un lab dédié.

Le fichier complet

📄 Voir le fichier .gitlab-ci.yml complet

stages:
  - lint
  - test
  - build
  - deploy

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_TAG
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "trigger"
    - if: $CI_PIPELINE_SOURCE == "api"

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.pip-cache"

ruff-lint:
  stage: lint
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
    policy: pull
  before_script:
    - pip install ruff
  script:
    - ruff check app/ tests/

pytest:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - echo "Pipeline source: $CI_PIPELINE_SOURCE"
    - pytest -v --junitxml=report.xml
  artifacts:
    when: always
    paths:
      - report.xml
    reports:
      junit: report.xml
    expire_in: 7 days

nightly-regression:
  stage: test
  image: python:3.12-slim
  cache:
    key:
      files:
        - requirements-dev.txt
    paths:
      - .pip-cache/
  before_script:
    - pip install -r requirements-dev.txt
  script:
    - echo "Nightly run on source=$CI_PIPELINE_SOURCE"
    - pytest -v
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

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

publish-package:
  stage: build
  image: python:3.12-slim
  script:
    - echo "Would publish package to GitLab Package Registry"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-staging:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to staging..."
    - ./scripts/deploy-demo.sh staging
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  image: alpine:3.20
  script:
    - echo "Deploying $CI_COMMIT_SHORT_SHA to production..."
    - ./scripts/deploy-demo.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual

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