Claude Code pour GitLab CI/CD est actuellement en version bêta. Les fonctionnalités peuvent évoluer à mesure que nous affinons l’expérience.

Cette intégration est maintenue par GitLab. Pour le support, consultez le problème GitLab suivant.

Cette intégration est construite sur la base du CLI et SDK Claude Code, permettant l’utilisation programmatique de Claude dans vos tâches CI/CD et flux de travail d’automatisation personnalisés.

Pourquoi utiliser Claude Code avec GitLab ?

  • Création instantanée de MR : Décrivez ce dont vous avez besoin, et Claude propose une MR complète avec les modifications et l’explication
  • Implémentation automatisée : Transformez les problèmes en code fonctionnel avec une seule commande ou mention
  • Conscient du projet : Claude suit vos directives CLAUDE.md et les modèles de code existants
  • Configuration simple : Ajoutez une tâche à .gitlab-ci.yml et une variable CI/CD masquée
  • Prêt pour l’entreprise : Choisissez l’API Anthropic, AWS Bedrock, ou Google Vertex AI pour répondre aux besoins de résidence des données et d’approvisionnement
  • Sécurisé par défaut : S’exécute dans vos runners GitLab avec votre protection de branche et vos approbations

Comment ça fonctionne

Claude Code utilise GitLab CI/CD pour exécuter des tâches IA dans des jobs isolés et valider les résultats via des MR :

  1. Orchestration pilotée par les événements : GitLab écoute vos déclencheurs choisis (par exemple, un commentaire qui mentionne @claude dans un problème, MR, ou fil de révision). Le job collecte le contexte du fil et du dépôt, construit des prompts à partir de cette entrée, et exécute Claude Code.

  2. Abstraction du fournisseur : Utilisez le fournisseur qui convient à votre environnement :

    • API Anthropic (SaaS)
    • AWS Bedrock (accès basé sur IAM, options inter-régions)
    • Google Vertex AI (natif GCP, Workload Identity Federation)
  3. Exécution en bac à sable : Chaque interaction s’exécute dans un conteneur avec des règles réseau et système de fichiers strictes. Claude Code applique des permissions limitées à l’espace de travail pour contraindre les écritures. Chaque modification passe par une MR pour que les réviseurs voient le diff et les approbations s’appliquent toujours.

Choisissez des points de terminaison régionaux pour réduire la latence et répondre aux exigences de souveraineté des données tout en utilisant les accords cloud existants.

Que peut faire Claude ?

Claude Code permet des flux de travail CI/CD puissants qui transforment votre façon de travailler avec le code :

  • Créer et mettre à jour des MR à partir de descriptions de problèmes ou de commentaires
  • Analyser les régressions de performance et proposer des optimisations
  • Implémenter des fonctionnalités directement dans une branche, puis ouvrir une MR
  • Corriger les bugs et régressions identifiés par les tests ou commentaires
  • Répondre aux commentaires de suivi pour itérer sur les modifications demandées

Configuration

Configuration rapide

Le moyen le plus rapide de commencer est d’ajouter un job minimal à votre .gitlab-ci.yml et de définir votre clé API comme variable masquée.

  1. Ajouter une variable CI/CD masquée

    • Allez dans ParamètresCI/CDVariables
    • Ajoutez ANTHROPIC_API_KEY (masquée, protégée si nécessaire)
  2. Ajouter un job Claude à .gitlab-ci.yml

stages:
  - ai

claude:
  stage: ai
  image: node:24-alpine3.21
  # Ajustez les règles selon la façon dont vous voulez déclencher le job :
  # - exécutions manuelles
  # - événements de merge request
  # - déclencheurs web/API quand un commentaire contient '@claude'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  variables:
    GIT_STRATEGY: fetch
  before_script:
    - apk update
    - apk add --no-cache git curl bash
    - npm install -g @anthropic-ai/claude-code
  script:
    # Optionnel : démarrer un serveur GitLab MCP si votre configuration en fournit un
    - /bin/gitlab-mcp-server || true
    # Utilisez les variables AI_FLOW_* lors de l'invocation via des déclencheurs web/API avec des charges utiles de contexte
    - echo "$AI_FLOW_INPUT for $AI_FLOW_CONTEXT on $AI_FLOW_EVENT"
    - >
      claude
      -p "${AI_FLOW_INPUT:-'Révisez cette MR et implémentez les modifications demandées'}"
      --permission-mode acceptEdits
      --allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
      --debug

Après avoir ajouté le job et votre variable ANTHROPIC_API_KEY, testez en exécutant le job manuellement depuis CI/CDPipelines, ou déclenchez-le depuis une MR pour laisser Claude proposer des mises à jour dans une branche et ouvrir une MR si nécessaire.

Pour s’exécuter sur AWS Bedrock ou Google Vertex AI au lieu de l’API Anthropic, consultez la section Utilisation avec AWS Bedrock et Google Vertex AI ci-dessous pour l’authentification et la configuration de l’environnement.

Configuration manuelle (recommandée pour la production)

Si vous préférez une configuration plus contrôlée ou avez besoin de fournisseurs d’entreprise :

  1. Configurer l’accès au fournisseur :

    • API Anthropic : Créez et stockez ANTHROPIC_API_KEY comme variable CI/CD masquée
    • AWS Bedrock : Configurez GitLabAWS OIDC et créez un rôle IAM pour Bedrock
    • Google Vertex AI : Configurez Workload Identity Federation pour GitLabGCP
  2. Ajouter les identifiants de projet pour les opérations API GitLab :

    • Utilisez CI_JOB_TOKEN par défaut, ou créez un Token d’Accès Projet avec la portée api
    • Stockez comme GITLAB_ACCESS_TOKEN (masqué) si vous utilisez un PAT
  3. Ajouter le job Claude à .gitlab-ci.yml (voir les exemples ci-dessous)

  4. (Optionnel) Activer les déclencheurs pilotés par mention :

    • Ajoutez un webhook de projet pour “Commentaires (notes)” à votre écouteur d’événements (si vous en utilisez un)
    • Faites en sorte que l’écouteur appelle l’API de déclenchement de pipeline avec des variables comme AI_FLOW_INPUT et AI_FLOW_CONTEXT quand un commentaire contient @claude

Exemples de cas d’usage

Transformer les problèmes en MR

Dans un commentaire de problème :

@claude implémentez cette fonctionnalité basée sur la description du problème

Claude analyse le problème et la base de code, écrit les modifications dans une branche, et ouvre une MR pour révision.

Obtenir de l’aide pour l’implémentation

Dans une discussion de MR :

@claude suggérez une approche concrète pour mettre en cache les résultats de cet appel API

Claude propose des modifications, ajoute du code avec la mise en cache appropriée, et met à jour la MR.

Corriger les bugs rapidement

Dans un commentaire de problème ou MR :

@claude corrigez la TypeError dans le composant tableau de bord utilisateur

Claude localise le bug, implémente une correction, et met à jour la branche ou ouvre une nouvelle MR.

Utilisation avec AWS Bedrock et Google Vertex AI

Pour les environnements d’entreprise, vous pouvez exécuter Claude Code entièrement sur votre infrastructure cloud avec la même expérience développeur.

Prérequis

Avant de configurer Claude Code avec AWS Bedrock, vous avez besoin de :

  1. Un compte AWS avec accès Amazon Bedrock aux modèles Claude désirés
  2. GitLab configuré comme fournisseur d’identité OIDC dans AWS IAM
  3. Un rôle IAM avec des permissions Bedrock et une politique de confiance restreinte à votre projet/refs GitLab
  4. Variables CI/CD GitLab pour l’assumption de rôle :
    • AWS_ROLE_TO_ASSUME (ARN du rôle)
    • AWS_REGION (région Bedrock)

Instructions de configuration

Configurez AWS pour permettre aux jobs CI GitLab d’assumer un rôle IAM via OIDC (pas de clés statiques).

Configuration requise :

  1. Activez Amazon Bedrock et demandez l’accès à vos modèles Claude cibles
  2. Créez un fournisseur OIDC IAM pour GitLab s’il n’est pas déjà présent
  3. Créez un rôle IAM approuvé par le fournisseur OIDC GitLab, restreint à votre projet et refs protégées
  4. Attachez des permissions de moindre privilège pour les API d’invocation Bedrock

Valeurs requises à stocker dans les variables CI/CD :

  • AWS_ROLE_TO_ASSUME
  • AWS_REGION

Ajoutez les variables dans Paramètres → CI/CD → Variables :

# Pour AWS Bedrock :
- AWS_ROLE_TO_ASSUME
- AWS_REGION

Utilisez l’exemple de job AWS Bedrock ci-dessus pour échanger le token de job GitLab contre des identifiants AWS temporaires à l’exécution.

Exemples de configuration

Ci-dessous se trouvent des extraits prêts à utiliser que vous pouvez adapter à votre pipeline.

.gitlab-ci.yml de base (API Anthropic)

stages:
  - ai

claude:
  stage: ai
  image: node:24-alpine3.21
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  variables:
    GIT_STRATEGY: fetch
  before_script:
    - apk update
    - apk add --no-cache git curl bash
    - npm install -g @anthropic-ai/claude-code
  script:
    - /bin/gitlab-mcp-server || true
    - >
      claude
      -p "${AI_FLOW_INPUT:-'Résumez les modifications récentes et suggérez des améliorations'}"
      --permission-mode acceptEdits
      --allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
      --debug
  # Claude Code utilisera ANTHROPIC_API_KEY des variables CI/CD

Exemple de job AWS Bedrock (OIDC)

Prérequis :

  • Amazon Bedrock activé avec accès à vos modèles Claude choisis
  • GitLab OIDC configuré dans AWS avec un rôle qui fait confiance à votre projet et refs GitLab
  • Rôle IAM avec permissions Bedrock (moindre privilège recommandé)

Variables CI/CD requises :

  • AWS_ROLE_TO_ASSUME : ARN du rôle IAM pour l’accès Bedrock
  • AWS_REGION : Région Bedrock (par exemple, us-west-2)
claude-bedrock:
  stage: ai
  image: node:24-alpine3.21
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
  before_script:
    - apk add --no-cache bash curl jq git python3 py3-pip
    - pip install --no-cache-dir awscli
    - npm install -g @anthropic-ai/claude-code
    # Échanger le token OIDC GitLab contre des identifiants AWS
    - export AWS_WEB_IDENTITY_TOKEN_FILE="${CI_JOB_JWT_FILE:-/tmp/oidc_token}"
    - if [ -n "${CI_JOB_JWT_V2}" ]; then printf "%s" "$CI_JOB_JWT_V2" > "$AWS_WEB_IDENTITY_TOKEN_FILE"; fi
    - >
      aws sts assume-role-with-web-identity
      --role-arn "$AWS_ROLE_TO_ASSUME"
      --role-session-name "gitlab-claude-$(date +%s)"
      --web-identity-token "file://$AWS_WEB_IDENTITY_TOKEN_FILE"
      --duration-seconds 3600 > /tmp/aws_creds.json
    - export AWS_ACCESS_KEY_ID="$(jq -r .Credentials.AccessKeyId /tmp/aws_creds.json)"
    - export AWS_SECRET_ACCESS_KEY="$(jq -r .Credentials.SecretAccessKey /tmp/aws_creds.json)"
    - export AWS_SESSION_TOKEN="$(jq -r .Credentials.SessionToken /tmp/aws_creds.json)"
  script:
    - /bin/gitlab-mcp-server || true
    - >
      claude
      -p "${AI_FLOW_INPUT:-'Implémentez les modifications demandées et ouvrez une MR'}"
      --permission-mode acceptEdits
      --allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
      --debug
  variables:
    AWS_REGION: "us-west-2"

Les ID de modèle pour Bedrock incluent des préfixes spécifiques à la région et des suffixes de version (par exemple, us.anthropic.claude-3-7-sonnet-20250219-v1:0). Passez le modèle désiré via votre configuration de job ou prompt si votre flux de travail le supporte.

Exemple de job Google Vertex AI (Workload Identity Federation)

Prérequis :

  • API Vertex AI activée dans votre projet GCP
  • Workload Identity Federation configurée pour faire confiance à GitLab OIDC
  • Un compte de service avec permissions Vertex AI

Variables CI/CD requises :

  • GCP_WORKLOAD_IDENTITY_PROVIDER : Nom de ressource fournisseur complet
  • GCP_SERVICE_ACCOUNT : Email du compte de service
  • CLOUD_ML_REGION : Région Vertex (par exemple, us-east5)
claude-vertex:
  stage: ai
  image: gcr.io/google.com/cloudsdktool/google-cloud-cli:slim
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
  before_script:
    - apt-get update && apt-get install -y git nodejs npm && apt-get clean
    - npm install -g @anthropic-ai/claude-code
    # S'authentifier à Google Cloud via WIF (pas de clés téléchargées)
    - >
      gcloud auth login --cred-file=<(cat <<EOF
      {
        "type": "external_account",
        "audience": "${GCP_WORKLOAD_IDENTITY_PROVIDER}",
        "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
        "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/${GCP_SERVICE_ACCOUNT}:generateAccessToken",
        "token_url": "https://sts.googleapis.com/v1/token"
      }
      EOF
      )
    - gcloud config set project "$(gcloud projects list --format='value(projectId)' --filter="name:${CI_PROJECT_NAMESPACE}" | head -n1)" || true
  script:
    - /bin/gitlab-mcp-server || true
    - >
      CLOUD_ML_REGION="${CLOUD_ML_REGION:-us-east5}"
      claude
      -p "${AI_FLOW_INPUT:-'Révisez et mettez à jour le code comme demandé'}"
      --permission-mode acceptEdits
      --allowedTools "Bash(*) Read(*) Edit(*) Write(*) mcp__gitlab"
      --debug
  variables:
    CLOUD_ML_REGION: "us-east5"

Avec Workload Identity Federation, vous n’avez pas besoin de stocker les clés de compte de service. Utilisez des conditions de confiance spécifiques au dépôt et des comptes de service à moindre privilège.

Meilleures pratiques

Configuration CLAUDE.md

Créez un fichier CLAUDE.md à la racine du dépôt pour définir les standards de codage, critères de révision, et règles spécifiques au projet. Claude lit ce fichier pendant les exécutions et suit vos conventions lors de la proposition de modifications.

Considérations de sécurité

Ne validez jamais les clés API ou identifiants cloud dans votre dépôt ! Utilisez toujours les variables CI/CD GitLab :

  • Ajoutez ANTHROPIC_API_KEY comme variable masquée (et protégez-la si nécessaire)
  • Utilisez OIDC spécifique au fournisseur quand possible (pas de clés à long terme)
  • Limitez les permissions de job et la sortie réseau
  • Révisez les MR de Claude comme tout autre contributeur

Optimisation des performances

  • Gardez CLAUDE.md focalisé et concis
  • Fournissez des descriptions de problème/MR claires pour réduire les itérations
  • Configurez des timeouts de job sensés pour éviter les exécutions incontrôlées
  • Mettez en cache les installations npm et de paquets dans les runners quand possible

Coûts CI

Lors de l’utilisation de Claude Code avec GitLab CI/CD, soyez conscient des coûts associés :

  • Temps de Runner GitLab :

    • Claude s’exécute sur vos runners GitLab et consomme des minutes de calcul
    • Consultez la facturation des runners de votre plan GitLab pour les détails
  • Coûts API :

    • Chaque interaction Claude consomme des tokens basés sur la taille du prompt et de la réponse
    • L’utilisation de tokens varie selon la complexité de la tâche et la taille de la base de code
    • Consultez la tarification Anthropic pour les détails
  • Conseils d’optimisation des coûts :

    • Utilisez des commandes @claude spécifiques pour réduire les tours inutiles
    • Définissez des valeurs max_turns et timeout de job appropriées
    • Limitez la concurrence pour contrôler les exécutions parallèles

Sécurité et gouvernance

  • Chaque job s’exécute dans un conteneur isolé avec accès réseau restreint
  • Les modifications de Claude passent par des MR pour que les réviseurs voient chaque diff
  • Les règles de protection de branche et d’approbation s’appliquent au code généré par IA
  • Claude Code utilise des permissions limitées à l’espace de travail pour contraindre les écritures
  • Les coûts restent sous votre contrôle car vous apportez vos propres identifiants de fournisseur

Dépannage

Claude ne répond pas aux commandes @claude

  • Vérifiez que votre pipeline est déclenchée (manuellement, événement MR, ou via un écouteur d’événement de note/webhook)
  • Assurez-vous que les variables CI/CD (ANTHROPIC_API_KEY ou paramètres de fournisseur cloud) sont présentes et non masquées
  • Vérifiez que le commentaire contient @claude (pas /claude) et que votre déclencheur de mention est configuré

Le job ne peut pas écrire de commentaires ou ouvrir des MR

  • Assurez-vous que CI_JOB_TOKEN a des permissions suffisantes pour le projet, ou utilisez un Token d’Accès Projet avec la portée api
  • Vérifiez que l’outil mcp__gitlab est activé dans --allowedTools
  • Confirmez que le job s’exécute dans le contexte de la MR ou a assez de contexte via les variables AI_FLOW_*

Erreurs d’authentification

  • Pour l’API Anthropic : Confirmez que ANTHROPIC_API_KEY est valide et non expirée
  • Pour Bedrock/Vertex : Vérifiez la configuration OIDC/WIF, l’usurpation de rôle, et les noms de secrets ; confirmez la disponibilité de la région et du modèle

Configuration avancée

Paramètres et variables communs

Claude Code supporte ces entrées couramment utilisées :

  • prompt / prompt_file : Fournissez des instructions en ligne (-p) ou via un fichier
  • max_turns : Limitez le nombre d’itérations aller-retour
  • timeout_minutes : Limitez le temps d’exécution total
  • ANTHROPIC_API_KEY : Requis pour l’API Anthropic (non utilisé pour Bedrock/Vertex)
  • Environnement spécifique au fournisseur : AWS_REGION, variables projet/région pour Vertex

Les drapeaux et paramètres exacts peuvent varier selon la version de @anthropic-ai/claude-code. Exécutez claude --help dans votre job pour voir les options supportées.

Personnaliser le comportement de Claude

Vous pouvez guider Claude de deux façons principales :

  1. CLAUDE.md : Définissez les standards de codage, exigences de sécurité, et conventions de projet. Claude lit ceci pendant les exécutions et suit vos règles.
  2. Prompts personnalisés : Passez des instructions spécifiques à la tâche via prompt/prompt_file dans le job. Utilisez différents prompts pour différents jobs (par exemple, révision, implémentation, refactorisation).