Ou tapez /gitlab-ci-guide dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.
🔑 Déclencheurs automatiques
Le skill s'active automatiquement quand votre demande contient :
GitLab CIgitlab-ci.ymlpipeline GitLabrunner GitLabGitLab CD
Concevoir le pipeline — Définir les stages du pipeline (build, test, analyze, deploy) dans .gitlab-ci.yml, identifier les jobs nécessaires à chaque stage, et déterminer les règles de déclenchement (rules, only/except).
Configurer les jobs — Écrire chaque job avec son image Docker, ses scripts (before_script, script, after_script), ses variables, et ses règles d'exécution conditionnelles basées sur la branche, les tags, les merge requests ou les modifications de fichiers.
Gérer les runners — Configurer les runners GitLab adaptés : shared runners pour les tâches standard, group runners pour les projets d'équipe, et specific runners pour les besoins spéciaux (GPU, accès réseau interne, Windows). Optimiser avec les tags et l'auto-scaling.
Optimiser avec le caching et les artifacts — Configurer le cache des dépendances (cache:key, cache:paths, cache:policy), les artifacts pour le partage entre jobs (artifacts:paths, artifacts:reports), et les dépendances explicites entre jobs (dependencies, needs).
Implémenter les environnements — Configurer les environnements de déploiement (environment:name, environment:url), les review apps dynamiques pour les merge requests, le stop des environnements temporaires, et les déploiements manuels avec protection.
Créer des pipelines avancés — Utiliser les pipelines enfants (trigger:include), les pipelines multi-projets (trigger:project), les templates partagés (include:template, include:remote), et le DAG (needs) pour la parallélisation optimale des jobs.
Intégrer la sécurité — Activer les scanners GitLab intégrés : SAST, DAST, dependency scanning, container scanning, secret detection. Configurer les politiques de merge basées sur les résultats de sécurité et les approval rules.
Règles
Utilise rules plutôt que only/except pour les conditions d'exécution — c'est la syntaxe recommandée et la plus flexible.
Configure toujours un cache approprié pour les dépendances afin de réduire les temps de pipeline.
Sépare la configuration en fichiers inclus (include:local) pour les projets avec des pipelines complexes plutôt qu'un seul fichier monolithique.
Protège les variables sensibles avec le masquage (masked: true) et la restriction aux branches protégées (protected: true).
Documente chaque job avec un commentaire expliquant son rôle dans le pipeline et ses dépendances.