Cas pratiques GitLab CI

Contexte : Un projet génère un dossier dist/ après la phase de build. Le Problème : Les fichiers générés ne sont pas conservés après l'exécution du job. Contraintes : Configurer les artifacts pour conserver le dossier dist/ entre les stages. Livrable attendu : Adapter le .gitlab-ci.yml pour inclure une configuration artifacts permettant de conserver les fichiers générés.

Contexte : Le pipeline actuel exécute uniquement les tests automatisés. Le Problème : L'équipe souhaite intégrer une étape de lint via npm run lint avant l'exécution des tests. Contraintes : Le job lint doit échouer si des erreurs sont détectées. Les stages doivent être organisés correctement. Livrable attendu : Modifier le .gitlab-ci.yml pour inclure une étape lint avant test dans un stage approprié.

Contexte : Une application nécessite une variable APP_ENV définie à test lors de l'exécution des tests. Le Problème : Le pipeline ne définit aucune variable d'environnement. Contraintes : Ajouter la variable dans le job test sans modifier le code applicatif. Livrable attendu : Adapter le fichier .gitlab-ci.yml pour injecter correctement la variable d'environnement dans le job concerné.

Contexte : Un pipeline GitLab CI échoue immédiatement avec une erreur YAML. Le Problème : Le bloc script semble mal structuré dans le fichier .gitlab-ci.yml. Configuration actuelle : test_job: stage: test script: - npm install - npm test Contraintes : Corriger uniquement l'indentation YAML sans modifier la logique. Livrable attendu : Fournir une version corrigée du job permettant au pipeline de s'exécuter correctement.

Contexte : Une équipe vient d'ajouter un fichier .gitlab-ci.yml dans un projet Node.js afin d'automatiser les tests. Le Problème : Malgré plusieurs commits, aucun pipeline ne se déclenche. Après analyse, le problème semble lié à la configuration des règles de déclenchement. Contraintes : Vous devez corriger uniquement le fichier .gitlab-ci.yml. Le pipeline doit se déclencher sur chaque push vers la branche main. Configuration actuelle : stages: - test test_job: stage: test script: - npm install - npm test only: - master Livrable attendu : Adapter la configuration pour que le pipeline s'exécute correctement sur la branche main.

Contexte : Une application nécessite Node 18 pour fonctionner. Le Problème : Le pipeline utilise actuellement une image node:16, provoquant des erreurs lors de l'exécution des scripts. Contraintes : Modifier uniquement la version de l'image dans le .gitlab-ci.yml. Configuration actuelle : image: node:16 Livrable attendu : Corriger la configuration pour utiliser la version Node appropriée.

Contexte : Un projet nécessite une phase de build puis une phase de test. Le Problème : Le pipeline actuel contient un seul job sans séparation logique des étapes. Contraintes : Définir deux stages distincts : build et test. Le stage test doit dépendre du build. Livrable attendu : Fournir un .gitlab-ci.yml structuré avec plusieurs stages correctement ordonnés.

Contexte : Un projet Node.js doit exécuter automatiquement ses tests à chaque push. Le Problème : Aucun pipeline CI n'est actuellement configuré dans le repository. Contraintes : Utiliser une image node:18 officielle. Installer les dépendances et exécuter npm test. Livrable attendu : Fournir un fichier .gitlab-ci.yml minimal permettant d'exécuter les tests à chaque push sur le repository.

Contexte : L'équipe souhaite que les pipelines s'exécutent uniquement lors de l'ouverture ou mise à jour d'une Merge Request. Le Problème : Actuellement, les pipelines se déclenchent sur tous les pushes. Contraintes : Configurer les règles pour déclencher le pipeline uniquement sur merge_request_events. Livrable attendu : Adapter le .gitlab-ci.yml pour limiter le déclenchement aux Merge Requests.

Contexte : Chaque exécution du pipeline réinstalle toutes les dépendances npm, rallongeant le temps d'exécution. Le Problème : Aucun mécanisme de cache n'est configuré dans le pipeline. Contraintes : Mettre en place un cache basé sur node_modules ou package-lock.json. Livrable attendu : Modifier le .gitlab-ci.yml pour intégrer une configuration de cache efficace afin d'accélérer les pipelines futurs.

Contexte : Une équipe souhaite pouvoir déclencher le déploiement en production uniquement après validation humaine. Le Problème : Le job de production se déclenche automatiquement à chaque merge sur main. Contraintes : Configurer le job de production pour qu'il soit manuel et visible dans l'interface GitLab. Livrable attendu : Adapter le .gitlab-ci.yml pour transformer le job de déploiement en action manuelle contrôlée.

Contexte : Un pipeline doit utiliser des identifiants sensibles pour déployer une application. Le Problème : Les variables sont actuellement définies en clair dans le fichier .gitlab-ci.yml. Contraintes : Utiliser les variables protégées configurées dans GitLab et restreindre leur utilisation aux branches protégées. Livrable attendu : Décrire une configuration pipeline sécurisée utilisant des variables CI/CD protégées sans exposer les secrets dans le repository.

Contexte : Le pipeline Node.js reste lent malgré un cache configuré. Le Problème : Le cache est invalidé trop souvent car la clé n'est pas correctement définie. Contraintes : Mettre en place une clé de cache basée sur le hash du fichier package-lock.json afin d'assurer une invalidation uniquement lorsque nécessaire. Livrable attendu : Adapter le .gitlab-ci.yml pour utiliser une clé dynamique garantissant un cache performant et cohérent.

Contexte : Un monorepo contient plusieurs services indépendants. Le Problème : Chaque modification déclenche l'ensemble des jobs même si un seul service est modifié. Contraintes : Utiliser rules:changes pour exécuter un job uniquement si certains dossiers sont modifiés. Livrable attendu : Adapter le .gitlab-ci.yml pour conditionner l'exécution des jobs selon les fichiers impactés.

Contexte : Une application doit construire et pousser une image Docker vers le GitLab Container Registry. Le Problème : L'authentification au registry échoue ou utilise des credentials non sécurisés. Contraintes : Utiliser les variables prédéfinies CI_REGISTRY_USER et CI_REGISTRY_PASSWORD. Livrable attendu : Proposer un job GitLab CI capable de builder et pousser une image Docker de manière sécurisée vers le registry intégré.

Contexte : Un projet comporte plusieurs branches longues (develop, release, main). Le Problème : Le pipeline actuel ne distingue pas les comportements selon le type de branche. Contraintes : Utiliser rules avec conditions sur CI_COMMIT_BRANCH pour adapter le comportement des jobs selon la branche. Livrable attendu : Fournir un .gitlab-ci.yml structuré permettant d'exécuter des jobs différents selon qu'il s'agit d'une branche develop, release ou main.

Contexte : Une application doit être déployée automatiquement en staging après chaque merge sur develop, puis en production uniquement depuis main. Le Problème : Le pipeline actuel déclenche le même déploiement sur toutes les branches, sans distinction d'environnement. Contraintes : Utiliser des rules ou only/except pour différencier les branches. Le job de production ne doit jamais s'exécuter depuis develop. Livrable attendu : Proposer un .gitlab-ci.yml structuré avec des jobs de déploiement distincts et des règles conditionnelles adaptées à chaque branche.

Contexte : Un projet contient plusieurs suites de tests (unitaires et intégration). Le Problème : Le pipeline exécute toutes les suites dans un seul job séquentiel, augmentant le temps total. Contraintes : Séparer les tests en plusieurs jobs exécutés en parallèle dans le même stage. Livrable attendu : Fournir un .gitlab-ci.yml structuré permettant l'exécution parallèle de plusieurs jobs de test pour réduire la durée globale du pipeline.

Contexte : Un job de test échoue parfois à cause de dépendances externes instables. Le Problème : Le pipeline est marqué failed même si l'échec est temporaire. Contraintes : Mettre en place une stratégie retry limitée sans masquer les erreurs persistantes. Livrable attendu : Adapter le .gitlab-ci.yml pour configurer un mécanisme retry sur le job concerné avec un nombre limité de tentatives.

Contexte : Un projet génère un build dans le stage build puis doit l'utiliser dans le stage deploy. Le Problème : Les fichiers générés ne sont pas accessibles dans le stage suivant. Contraintes : Configurer correctement artifacts et dependencies pour transmettre les fichiers entre stages. Livrable attendu : Fournir un .gitlab-ci.yml démontrant le transfert d'artefacts du stage build vers deploy.

Contexte : Une organisation possède plusieurs repositories GitLab distincts (backend, frontend, infra). Chaque projet doit déclencher un pipeline coordonné dans le projet infra lors d'une release. Le Problème : Les pipelines sont actuellement isolés et aucune orchestration inter-projets n'est en place. Contraintes : Utiliser trigger ou pipeline multi-project natif GitLab. L'authentification doit être sécurisée via CI_JOB_TOKEN ou token dédié. Livrable attendu : Proposer une configuration .gitlab-ci.yml permettant de déclencher proprement un pipeline distant tout en garantissant la sécurité des échanges.

Contexte : Un pipeline existant fonctionne mais n'a jamais été audité du point de vue sécurité et performance. Le Problème : Les permissions sont larges, les caches mal configurés et certaines étapes inutiles ralentissent la CI. Contraintes : Proposer une refonte complète du .gitlab-ci.yml en appliquant principe du moindre privilège, optimisation des stages et suppression des redondances. Livrable attendu : Décrire une stratégie d'audit et une version optimisée du pipeline garantissant sécurité, performance et maintenabilité.

Contexte : Une application nécessite des secrets critiques pour accéder à des services externes. Le Problème : Certains secrets apparaissent dans les logs du pipeline à cause d'une mauvaise configuration. Contraintes : Utiliser des variables protégées et masquées. Restreindre leur utilisation aux branches protégées uniquement. Livrable attendu : Proposer une stratégie complète de gestion des variables CI/CD garantissant qu'aucune donnée sensible ne soit exposée dans les logs.

Contexte : Un repository contient des manifestes Kubernetes versionnés qui doivent être validés puis appliqués automatiquement. Le Problème : Les changements d'infrastructure ne sont pas validés avant déploiement. Contraintes : Ajouter des étapes de validation (lint, kubectl dry-run) puis un déploiement conditionnel uniquement sur main. Livrable attendu : Proposer une configuration GitLab CI adaptée à une stratégie GitOps sécurisée et contrôlée.

Contexte : Un monorepo contient plusieurs microservices indépendants qui doivent être buildés séparément selon les modifications. Le Problème : Le pipeline actuel est monolithique et difficile à maintenir. Contraintes : Utiliser les child pipelines dynamiques avec include et rules:changes. Aucun outil externe autorisé. Livrable attendu : Proposer une architecture GitLab CI utilisant des pipelines enfants générés dynamiquement selon les dossiers modifiés.

Contexte : Une application doit être versionnée automatiquement à chaque release stable. Le Problème : Les versions sont actuellement gérées manuellement sans cohérence. Contraintes : Déclencher un job spécifique lors de la création d'un tag Git et générer une release cohérente. Livrable attendu : Proposer une configuration GitLab CI permettant de déclencher automatiquement des jobs sur création de tag et gérer les releases proprement.

Contexte : Un projet complexe utilise Node.js, Docker et Terraform dans le même pipeline. Le Problème : Chaque exécution reconstruit intégralement les dépendances, ralentissant fortement la CI. Contraintes : Mettre en place des caches distincts pour npm, Docker layers et Terraform providers. Garantir une invalidation cohérente. Livrable attendu : Proposer une architecture .gitlab-ci.yml optimisée avec plusieurs niveaux de cache correctement configurés.

Contexte : Un pipeline complexe comporte plusieurs jobs interdépendants avec différents chemins d'exécution selon les résultats intermédiaires. Le Problème : Le pipeline actuel est linéaire et ne permet pas de gérer des scénarios conditionnels complexes. Contraintes : Utiliser needs, rules et allow_failure pour orchestrer dynamiquement l'exécution des jobs. Livrable attendu : Décrire un pipeline structuré permettant une orchestration conditionnelle avancée et optimisée.

Contexte : Une entreprise dispose de plusieurs runners GitLab (linux, windows, macos) pour builds multi-plateformes. Le Problème : Les jobs ne sont pas correctement distribués selon les capacités des runners. Contraintes : Utiliser tags de runners et parallélisation adaptée pour optimiser la durée du pipeline. Livrable attendu : Décrire un pipeline GitLab CI capable d'orchestrer des builds multi-plateformes via runners dédiés.

Contexte : Une application critique doit être déployée sans interruption de service sur un environnement Kubernetes. Le Problème : Les déploiements actuels remplacent directement la version en production sans possibilité de rollback rapide. Contraintes : Mettre en place deux environnements (blue et green) et automatiser la bascule via pipeline. Prévoir une étape de rollback conditionnelle. Livrable attendu : Décrire une configuration GitLab CI structurée permettant un déploiement blue-green avec validation et rollback automatisé.