Les variables CI/CD dans GitLab : Dynamiser vos automatisations
Le moteur de personnalisation de vos pipelines
Dans un pipeline automatisé, vous avez souvent besoin de manipuler des informations qui changent d'un projet à l'autre ou d'un environnement à l'autre. Pour gérer cela, GitLab utilise les Variables CI/CD.
Imaginez que vos variables sont des étiquettes intelligentes collées sur votre code. Au lieu d'écrire "en dur" le nom de votre serveur dans vos scripts, vous utilisez une étiquette nommée $CI_ENVIRONMENT_URL. Le système remplacera automatiquement cette étiquette par la bonne valeur au moment de l'exécution. De nos jours, cette flexibilité est la base de l'infrastructure as code.
Visualiser les variables en action
Il est très facile de voir ce que contiennent ces variables en ajoutant une simple commande d'affichage dans votre fichier .gitlab-ci.yml.
Exemple de configuration YAML
test_job:
stage: test
script:
- echo "Je travaille sur la branche $CI_COMMIT_REF_NAME"
- echo "L'ID du projet est $CI_PROJECT_ID"Sortie terminal :
Running with gitlab-runner 17.10.0
[...]
$ echo "Je travaille sur la branche $CI_COMMIT_REF_NAME"
Je travaille sur la branche main
$ echo "L'ID du projet est $CI_PROJECT_ID"
L'ID du projet est 456782
Job succeededListe des variables prédéfinies GitLab
GitLab fournit par défaut une liste impressionnante de variables prêtes à l'emploi que vous pouvez retrouver sur la documentation officielle. Voici les plus courantes pour piloter vos builds :
| Variable | Description |
|---|---|
| CI_COMMIT_REF_NAME | Le nom de la branche (ex: main) ou du tag utilisé pour le build. |
| CI_COMMIT_SHA | L'identifiant complet (hash) du commit en cours de traitement. |
| CI_JOB_ID | L'identifiant unique du job actuel dans GitLab. |
| CI_PROJECT_DIR | Le chemin complet où le dépôt a été cloné sur le Runner. |
| CI_REGISTRY_IMAGE | L'adresse du registre Docker propre à votre projet. |
| GITLAB_USER_EMAIL | L'adresse email de l'utilisateur qui a déclenché le pipeline. |
Variables de groupe et de projet
Au-delà des variables automatiques, vous pouvez créer vos propres variables (clés d'API, mots de passe de base de données) directement dans l'interface GitLab pour ne pas les afficher en clair dans votre code. Ces éléments critiques sont généralement gérés par les utilisateurs ayant le rôle Maintainer.
- Allez dans Settings > CI/CD.
- Dépliez la section Variables.
- Cliquez sur Add variable.
"Interface d'ajout de variables personnalisées dans GitLab"
Sécurité : Masked & Protected
Pour vos secrets, utilisez toujours l'option Masked. Cela permet de cacher la valeur de la variable dans les logs de la console (elle sera remplacée par [MASKED]) pour éviter que vos mots de passe ne soient visibles par toute l'équipe.
Conclusion
Les variables CI/CD transforment vos pipelines statiques en outils dynamiques capables de s'adapter à n'importe quelle situation. C'est l'outil indispensable pour gérer vos déploiements sur différents environnements (Staging, Production) sans erreur humaine.
Maintenant que vous savez manipuler les données de vos jobs, nous allons voir comment sécuriser tout cela. Dans le prochain chapitre, nous allons détailler les Permissions spécifiques à GitLab CI.
Espace commentaire
Écrire un commentaire
Vous devez être connecté pour poster un message !
18 commentaires
actif
OK, ça explique pas mal de choses sur l'usage des `CI_*` variables. C'est vraiment la base de l'IaC, mais les gens oublient de bien séparer les *credentials* projet/environnement (les vrais secrets) des variables d'exécution (les `CI_*`).
actif
Merci pour l'exemple `test_job`. C'est parfait pour les novices. J'ai juste un point de vigilance : faire un `echo $CI_COMMIT_SHA` ça montre le SHA, mais si tu passes en tag, tu devrais aussi vérifier si ton script gère correctement le préfixe `v` que les tags ont souvent.
On a migré un vieux stack qui utilisait des variables hardcodées dans un fichier `config.yml` par CI/CD variables. C'était un cauchemar de maintenabilité.
Attention au concept de `Protected` variables. Si tu laisses une variable `protected` mais que le pipeline est lancé depuis un branch non-protégé, ça ne fonctionnera pas. C'est un piège classique.
Super récap des variables prédéfinies. Si je peux me permettre, il serait utile de rappeler que pour les multi-cluster deployments, on utilise souvent les variables spécifiques au 'target' ou au 'namespace' qui sont gérées par des outils externes (Terraform/Helm), et pas seulement les `CI_*` natives de GitLab.
Le passage par l'interface pour définir des variables de groupe/projet est le bon réflexe sécurité. En production, on ne doit jamais passer de `secrets` comme mot de passe DB directement dans le `script` sans que ça soit via une variable masquée et protégée.
Quand vous parlez de `$CI_PROJECT_DIR`, n'oubliez pas que cela est utile mais pas forcément suffisant pour les grosses architectures. Si vous utilisez des *volumes* montés à un niveau supérieur, il faudra des chemins relatifs au niveau du runner, pas seulement du clone.
Le plus souvent, ce qui manque, c'est de bien ségréguer les variables par environnement. Un `$DOCKER_PASSWORD` pour `staging` ne doit jamais être accessible au job de `develop` par défaut. Il faut des *masking* et des *scope* très précis.
J'ai remarqué que certaines personnes confondent les variables de *build* (checkout, SHA) et les variables *runtime* (credentials DB, API Key). Ça nécessite une séparation de jobs très stricte pour la sécurité.
Très bonne synthèse sur les bonnes pratiques de CI/CD. Mais quand on scale, le problème n'est pas la variable elle-même, mais l'accès sécurisé à ce service de variables (Vault, AWS Secrets Manager, etc.) que le runner doit pouvoir contacter. GitLab n'est qu'un déclencheur.
rédacteur
Confirmation sur le rôle des variables d'environnement. C'est la seule manière propre de ne pas contaminer le code source avec des secrets de déploiement. C'est le socle de l'automatisation moderne.
Niveau sécurité : Est-ce que les variables de groupe ou de projet sont *automatiquement* masquées quand elles sont utilisées dans le log, même si elles ne sont pas explicitement *masked* ? Il faut double-check ce comportement de GitLab pour être sûr.
Je travaille beaucoup avec `CI_ENVIRONMENT_URL` et les variables spécifiques aux déploiements (ex: `NPM_CACHE_DIR`). L'intégration des variables au niveau du namespace est souvent plus puissante que le simple scope de projet.
Petit point technique sur les dépendances. Quand on utilise des variables pour les chemins de déploiement, on doit faire gaffe aux différences de casse (case sensitivity) entre le Runner Linux et un Runner Windows si jamais on est sur un stack hybride.
Très clair. L'IaC repose sur cette capacité à ne pas coder en dur. C'est la passerelle entre le Git et le runtime. Bravo pour le récap des variables `CI_COMMIT_SHA` et `CI_COMMIT_REF_NAME`.
actif secouriste
Pour ceux qui déplacent des services très sensibles, pensez à ne pas utiliser seulement la variable pour le secret lui-même, mais aussi le contexte (l'environnement) pour la validation de *who* peut *deploy* quoi. C'est au niveau du rôle GitLab.
Good article sur les basics, mais en production, on passe de l'utilisation des variables CI/CD internes à une gestion de secrets externe et centralisée (comme HashiCorp Vault) appelée via un *Sidecar Container* dans le job. C'est plus robuste et auditable.
L'outil `echo` est très basique pour voir la variable. Si tu veux la voir dans un contexte réseau, tu vas devoir l'injecter dans les headers des requêtes HTTP faites par curl/wget pour valider qu'elle est bien présente.
Génial le rappel sur les `Maintainer` droits. On doit aussi se méfier des *runner credentials* eux-mêmes. Assure-toi que le job ne peut pas être manipulé pour accéder à des secrets qu'il ne devrait pas connaître.