✦ Nouveau • Compétence d'IA gratuite

Rédigez et validez vos pipelines GitLab CI sans quitter votre éditeur de code

Une compétence d'IA gratuite qui rédige et valide votre fichier .gitlab-ci.yml dans votre éditeur de code local. Compatible avec Cursor, VS Code, Claude Code et tout autre agent.

0compte GitLab requis pour valider en local
Plus de 6agents d'IA et éditeurs de code pris en charge
MITopen source (compétence et CLI)
Ce qui change

De commit-puis-validation à validation-puis-commit

Les pipelines restent la seule partie de la pile de développement moderne que vous ne pouvez toujours pas valider en local. La compétence rédige le fichier YAML dans votre éditeur de code. glci (un projet GitLab expérimental) l'exécute dans le runner réel avant que vous n'effectuiez un push. Vous n'avez plus besoin d'utiliser votre pipeline distant comme débogueur ni votre historique git comme log de fautes de frappe.

Avant

Effectuer un commit. Effectuer un push. Attendre. Échouer. Recommencer.

  • Écrire le fichier YAML à la main, de mémoire ou à l'aide de la documentation
  • Effectuer un commit et un push sur une branche pour voir si tout fonctionne
  • Attendre un runner distant pendant 8 à 12 minutes
  • Échouer à cause d'une faute de frappe, d'une variable manquante ou d'un job mal nommé
  • Modifier, effectuer un push, recommencer 3 à 4 fois
  • Polluer l'historique avec de nombreux commits « fix CI »
Avec la compétence + glci

Rédiger. Valider. Effectuer un push quand le pipeline est au vert.

  • Demander à l'agent de rédiger un pipeline à partir de votre dépôt
  • Exécuter glci show pour inspecter le graphe des jobs
  • Exécuter glci run pour lancer chaque job dans un environnement Docker réel
  • Corriger les problèmes en quelques secondes seulement
  • Effectuer un seul push, avec un pipeline que vous avez déjà vu réussir
  • Conserver un historique git centré sur votre code et non sur votre fichier YAML

Ce qui change, ce n'est pas la vitesse du pipeline, mais votre relation avec celui-ci. La même relation que vous avez déjà avec le code de votre application.

Premiers pas

Deux étapes, environ cinq minutes

Aucun compte GitLab n'est nécessaire pour valider en local. Aucun push n'est effectué tant que vous ne l'avez pas décidé.

01~1 minute

Ajoutez la compétence à votre éditeur de code

Déposez la compétence dans Claude Code, Cursor, VS Code, OpenCode ou Codex. L'agent connaît désormais GitLab CI/CD : la syntaxe, les bonnes pratiques et votre pile.

02~3 minutes

Demandez, exécutez, effectuez un push

« Write a CI pipeline for this project. » Relisez le fichier YAML rédigé par l'agent. Exécutez glci run. Effectuez un push quand le pipeline est au vert.

Ce qu'il vous faut

  • Un éditeur de code ou un agent compatibleClaude Code, Cursor, VS Code, OpenCode, Codex ou tout outil qui charge des compétences en Markdown.
  • Un projetN'importe quel code source, hébergé n'importe où. L'agent lit votre répertoire de travail local et rédige automatiquement une suggestion de pipeline.
  • Docker exécuté en localPour que glci puisse valider et exécuter les jobs dans des conteneurs réels.
  • Un projet GitLab(lorsque vous êtes prêt à exécuter la CI à chaque push)La compétence et glci n'en ont pas besoin pour valider en local, mais il vous faudra un projet quand vous voudrez exécuter les pipelines dans le cloud.
Installation

Compatible avec vos agents d'IA actuels

Une CLI pour exécuter les pipelines en local et une compétence pour les rédiger dans votre éditeur de code. Installez-les dans l'ordre qui vous convient.

Ajoutez la compétence à votre éditeur de code

Choisissez votre agent

Téléchargez la compétence et apprenez où placer les fichiers pour que Cursor les repère.

git clone https://gitlab.com/gitlab-org/ci-cd/gitlab-ci-skill.git ~/.cursor/skills/gitlab-ci-skill

Rechargez Cursor. L'agent utilise automatiquement la compétence lorsque vous saisissez le prompt : "Write a CI pipeline for this project."

Pourquoi utiliser GitLab

Plus qu'un runner, plus qu'une compétence

Personne ne souhaite se connecter à l'interface utilisateur pour écrire un pipeline. Cette compétence vous permet de rester dans votre éditeur de code aussi longtemps que possible. Mais il faut parfois revenir en arrière à cause d'un pipeline en échec, d'une revue de merge request ou d'un déploiement qui ne fonctionne pas comme prévu. Lorsque cela arrive, la plateforme est déjà connectée. Le code, les pipelines, le registre, les secrets et les déploiements résident tous au même emplacement. Quel que soit l'éditeur de code ou l'agent que vous utilisez, l'intégration fonctionne. Les mêmes contrôles de sécurité s'appliquent au code écrit par l'IA et au vôtre.

Un seul modèle de données. Ouvert en périphérie.

Code, pipelines, paquets, résultats de sécurité, déploiements, releases : tous ces éléments sont reliés au sein d'un même système plutôt que synchronisés. Quel que soit l'éditeur, l'agent ou le modèle que vous choisissez, il s'intègre via MCP et utilise la même vue de référence. Ouvert en périphérie, gouverné au centre.

Le contexte, élément décisif entre l'IA rapide et l'IA fiable.

Sans contexte, les agents écrivent du code qui semble correct et échoue dans l'environnement de production, car ils ne voient pas ce qui dépend d'un changement ni ce qui existe déjà. Le graphe de connaissances de GitLab cartographie en temps réel les liens entre votre code, vos pipelines, vos déploiements et les résultats de sécurité. Les questions sur le rayon d'impact ou l'impact downstream trouvent une réponse en quelques secondes au lieu de plusieurs jours. Tout agent peut le consulter.

Une gouvernance structurelle, pas ajoutée après coup.

Le code écrit par l'IA passe par les mêmes scans de sécurité, les mêmes approbations et la même piste d'audit que le code que vous écrivez. Les agents disposent d'identités limitées, de politiques comportementales et d'une chaîne de possession complète. Utilisez votre propre modèle, votre propre cloud, votre propre agent : tout est gouverné par la même structure.

Du traditionnel à l'autonome, sur la même plateforme.

Certaines de vos équipes continueront d'écrire du code à la main. D'autres dirigeront des agents sur des tâches précises. Quelques-unes laisseront des agents travailler en autonomie sur des sujets à faible risque. Ces trois approches reposent sur le même modèle de données et la même gouvernance. Chaque équipe progresse à son rythme, sans changer de plateforme à mesure que sa maturité IA évolue.

Nous développons activement cette compétence, et l'équipe qui la construit souhaite qu'elle s'adapte à votre façon de travailler. Dites-nous ce qui vous plaît et ce qui vous freine. Faites-nous part de vos commentaires.

Aller plus loin

Deux autres points où l'IA de GitLab s'intègre à votre CI

La compétence GitLab CI est conçue pour la rédaction et la validation de nouveaux pipelines dans votre éditeur de code. Lorsque votre travail CI/CD change de nature, GitLab propose des produits complémentaires qui s'adaptent.

Compétence d'IA gratuite · Migration

Vous venez de GitHub Actions ?

La compétence de migration de GitHub Actions lit votre fichier .github/workflows/ et le convertit en pipeline GitLab CI/CD idiomatique, en signalant tout élément qui nécessite une décision manuelle. Mêmes éditeurs de code, même workflow.

Découvrir la compétence de migration
GitLab Duo Agent Platform

Votre pipeline devient complexe ?

L'agent CI Expert réside au sein de GitLab Duo Agent Platform avec un contexte de projet complet : lecture des job logs en temps réel, optimisation des temps de build, débogage des jobs instables et prise en charge des pipelines multi-projets. Vous pouvez ainsi passer de l'écriture des pipelines à leur exploitation.

Découvrir l'agent CI Expert

Ne déboguez plus en production

Rédigez le pipeline. Exécutez-le en local. Effectuez un push quand le pipeline est au vert.