Exercice 03 : Utiliser les variables prédéfinies GitLab

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

• ✅ Identifier et utiliser les variables prédéfinies GitLab les plus courantes
• ✅ Afficher $CI_COMMIT_SHORT_SHA, $CI_PROJECT_NAME, $CI_PIPELINE_URL
• ✅ Déclarer vos propres variables avec variables: au niveau global et par job
• ✅ Comprendre la différence entre variable globale et variable de job

Durée estimée : 15 minutes

Difficulté : ⭐☆☆☆☆ (Débutant)

Prérequis :

• Exercice 01 et 02 complétés
• Compte GitLab.com avec un projet

📖 Contexte

GitLab injecte automatiquement des dizaines de variables dans chaque job. Ces variables permettent à vos scripts de connaître le contexte d'exécution : quelle branche, quel commit, quel utilisateur a déclenché le pipeline. Vous pouvez aussi définir vos propres variables pour éviter la duplication dans vos scripts.

📋 Énoncé

Créez un pipeline qui explore les variables prédéfinies GitLab et définit ses propres variables personnalisées. Un job debug-env affichera toutes les variables importantes, un job build-tag utilisera $CI_COMMIT_SHORT_SHA pour créer un tag d'image Docker simulé.

🧭 Déroulement de l'exercice

Tâche 1 : Créer un job de debug des variables

Créez un job debug-env dans un stage info. Il doit afficher avec echo les 5 variables suivantes : $CI_COMMIT_BRANCH, $CI_COMMIT_SHORT_SHA, $CI_PROJECT_NAME, $CI_PIPELINE_URL, $CI_COMMIT_AUTHOR.

Indice : Chaque echo sur une ligne séparée dans script: s'exécute en ordre. Les variables prédéfinies sont disponibles dans TOUS les jobs sans déclaration préalable.

Vérification : Les 5 variables sont affichées dans les logs avec leurs valeurs réelles.

Tâche 2 : Déclarer une variable globale personnalisée

Au niveau racine du .gitlab-ci.yml, déclarez une section variables: avec APP_VERSION: "1.0.0" et ENVIRONMENT: "staging". Créez un job show-version qui affiche ces deux variables.

Indice :

`yaml

variables:

APP_VERSION: "1.0.0"

ENVIRONMENT: "staging"

`

Les variables définies au niveau racine sont disponibles dans tous les jobs du pipeline.

Vérification : show-version affiche APP_VERSION=1.0.0 et ENVIRONMENT=staging.

Tâche 3 : Surcharger une variable dans un job

Dans le job build-tag, redéfinissez ENVIRONMENT: "production" localement. Cette valeur doit écraser la valeur globale uniquement pour ce job.

Indice : Une section variables: dans un job a priorité sur la section variables: globale. Les autres jobs conservent la valeur globale.

Vérification : build-tag affiche ENVIRONMENT=production tandis que les autres jobs affichent ENVIRONMENT=staging.

Tâche 4 : Construire un tag d'image avec $CI_COMMIT_SHORT_SHA

Dans le job build-tag, composez une variable IMAGE_TAG qui combine $CI_PROJECT_NAME et $CI_COMMIT_SHORT_SHA, puis affichez-la.

Indice : Les variables GitLab peuvent être utilisées dans d'autres variables :

`yaml

IMAGE_TAG: "$CI_PROJECT_NAME:$CI_COMMIT_SHORT_SHA"

`

C'est un pattern courant pour tagger des images Docker avec le SHA du commit.

Vérification : IMAGE_TAG affiche quelque chose comme mon-projet:a1b2c3d4.

Tâche 5 : Afficher l'utilisateur déclencheur

Ajoutez dans le job debug-env l'affichage de $GITLAB_USER_NAME (nom de l'utilisateur GitLab qui a déclenché le pipeline) et $CI_PIPELINE_SOURCE (comment le pipeline a été déclenché : push, web, schedule, etc.).

Indice : $CI_PIPELINE_SOURCE vaut push quand vous faites git push. Il vaut web si vous déclenchez manuellement depuis l'interface GitLab.

Vérification : Les logs affichent votre nom d'utilisateur GitLab et la source push.

🗂️ Mini-Projet : Tableau de bord des variables

Checkpoints de validation :

• $CI_COMMIT_SHORT_SHA est un hash de 8 caractères dans les logs
• $CI_PIPELINE_URL contient une URL cliquable vers le pipeline
• La variable APP_VERSION est correctement surchargée dans build-tag
• IMAGE_TAG combine bien le nom du projet et le SHA du commit
• $GITLAB_USER_NAME affiche votre nom d'utilisateur GitLab