Revoyez vos merge requests GitLab avec Codex

Utilisez la revue de code de Codex pour obtenir un regard supplémentaire sur les problèmes importants dans vos merge requests GitLab. Codex examine le diff de la merge request, suit les consignes de votre dépôt et publie une revue de code au format habituel de GitLab en se concentrant sur les problèmes graves.

L’intégration de revue de code pour GitLab est en bêta et disponible avec toutes les offres ChatGPT. Elle s’exécute dans Codex Cloud. Cette bêta n’inclut pas les commandes de gestion de dépôt que l’application de bureau ChatGPT propose pour GitHub, comme Créer une pull request.

Si GitLab apparaît dans le sélecteur de dépôts lorsque vous créez un environnement cloud, sélectionnez un projet GitLab.com auquel votre compte connecté a accès. Pour les tâches et les revues déclenchées depuis GitLab, configurez les webhooks comme indiqué ci-dessous.

Avant de commencer

Assurez-vous de disposer des éléments suivants :

• Un compte GitLab connecté. Pour GitLab.com, suivez la procédure de connexion standard. Pour une instance GitLab autogérée ou GitLab Dedicated, un administrateur de l’espace de travail doit configurer le modèle de connexion.
• Un fichier AGENTS.md si vous souhaitez que Codex suive des consignes de revue propres au dépôt.

Configurez la revue de code avec Codex

Configurez la connexion à GitLab et le compte utilisé par Codex pour les revues

Pour GitLab.com, connectez votre compte GitLab dans Codex après avoir connecté GitLab dans ChatGPT. Pour une instance GitLab autogérée ou GitLab Dedicated, chaque personne chargée des revues doit connecter son compte après la publication du modèle de connexion par l’administrateur de l’espace de travail.

Pour une instance GitLab autogérée ou GitLab Dedicated, ouvrez Codex Cloud → Paramètres → Connecteurs. Un administrateur de l’espace de travail peut laisser Codex créer un compte de service ou enregistrer le jeton d’accès personnel d’un compte de service existant.

Laissez Codex créer le compte

Dans Codex Cloud → Paramètres → Connecteurs, sélectionnez l’application correspondant à votre instance GitLab autogérée ou GitLab Dedicated, puis Configurer un compte de service → Créer un compte de service. L’administrateur de l’espace de travail qui effectue la configuration doit disposer des droits d’administration sur l’instance GitLab. Choisissez Groupes sélectionnés ou Projets sélectionnés uniquement, sélectionnez les groupes ou projets dans lesquels Codex doit intervenir, puis créez le compte. La première option attribue au compte le rôle Developer dans chaque groupe choisi. Les projets et sous-groupes de ces groupes héritent de ce rôle. La seconde option attribue le rôle Developer uniquement dans les projets que vous choisissez. Codex crée le compte de service d’instance ChatGPT Codex Connector et le dote d’un jeton d’accès personnel de portée api.

Utilisez un compte existant

Dans GitLab, créez ou choisissez un compte de service et attribuez-lui le rôle Developer uniquement dans les groupes ou projets où Codex doit intervenir. Sur la page Comptes de service, sélectionnez le compte, puis Gérer les jetons d’accès → Ajouter un jeton pour créer un jeton d’accès personnel de portée api qui expirera dans au moins 30 jours. De retour dans Codex, choisissez Utiliser un compte de service existant, collez le jeton et sélectionnez Enregistrer le jeton. Codex chiffre le jeton à l’enregistrement et ne l’affiche plus par la suite.

Gérez le jeton du compte de service

Les administrateurs de l’espace de travail peuvent gérer le compte de service dans Codex Cloud → Paramètres → Connecteurs. Si Codex a créé le compte, les administrateurs peuvent révoquer le jeton actuel et en générer un nouveau. Pour un compte existant, ils peuvent remplacer ou supprimer le jeton enregistré dans Codex et, si nécessaire, le révoquer séparément dans GitLab. Codex ne peut réagir aux événements GitLab qu’une fois un jeton valide configuré.

Choisissez comment transmettre les événements GitLab à Codex

Créez un environnement de projet pour les tâches de développement ou les configurations propres au projet

Dans Codex Cloud → Paramètres → Environnements, choisissez le projet GitLab et créez un environnement de projet si vous souhaitez que Codex écrive ou exécute du code pour ce projet, par exemple pour modifier des fichiers, créer des commits ou pousser des modifications vers la branche d’une merge request. Créez également un environnement si une revue nécessite des secrets, un accès réseau ou des commandes de configuration propres au projet.

Sur GitLab.com, un environnement de projet est également nécessaire pour activer les revues Codex.

Lors de la création de l’environnement, activez Activer l’activité Codex depuis GitLab pour installer le webhook de projet qui transmet à Codex les événements liés aux merge requests, aux commentaires et aux tickets. Pour créer ce webhook, vous devez disposer du rôle Maintainer ou Owner, de droits d’administration ou d’un rôle personnalisé qui permet d’administrer les webhooks de projet. Les webhooks signés de projet et de groupe nécessitent GitLab 19.0 ou une version ultérieure. Sur une instance GitLab 19.0 autogérée, vérifiez que l’indicateur de fonctionnalité webhook_signing_token est activé. Il est activé par défaut dans cette version et a été supprimé dans GitLab 19.1.

Activez la transmission des événements pour les revues Codex dans tous les projets d’un groupe GitLab

Pour une instance GitLab autogérée ou GitLab Dedicated, les administrateurs de l’espace de travail peuvent ouvrir Environnements → Activité GitLab → Gérer les groupes pour activer les revues Codex dans un groupe et ses sous-groupes. Codex installe alors un webhook de groupe qui couvre tous les projets du groupe. L’utilisateur GitLab connecté doit avoir le rôle Owner dans le groupe. Les webhooks de groupe nécessitent l’offre GitLab Premium ou Ultimate et GitLab 19.0 ou une version ultérieure.

Activer la transmission des événements du groupe permet d’effectuer des revues de code, mais ne crée aucun environnement de projet. Pour exécuter des tâches de développement déclenchées depuis GitLab, comme modifier des fichiers, exécuter des commandes, créer des commits ou pousser des modifications vers une merge request, créez un environnement de projet.

Configurez les politiques de revue de code

Configurez les politiques de revue de code dans les paramètres de revue de Codex. Choisissez votre dépôt, puis activez Revue automatique dans Examiner le code. Utilisez Revue pour choisir les personnes dont les merge requests feront l’objet d’une revue et Déclencheur pour choisir quand lancer les revues. Les paramètres du dépôt peuvent prendre le pas sur vos paramètres personnels par défaut.

Demandez une revue à Codex

1. Dans un commentaire de la merge request, mentionnez @codex review.
2. Attendez que Codex réagisse (👀) et publie sa revue.

Codex ouvre des discussions GitLab et publie des notes sur la merge request, comme le ferait un membre de votre équipe. Par défaut, les revues demandées manuellement peuvent signaler des problèmes de priorité P0, P1 et P2, tandis que les revues automatiques se concentrent sur les priorités P0 et P1.

Activez les revues automatiques

Pour examiner automatiquement les merge requests qui remplissent les critères, activez Revues automatiques dans les paramètres de Codex, choisissez la politique du dépôt GitLab, puis sélectionnez un déclencheur : À l’ouverture de la merge request, À chaque push ou Déclencheur intelligent (expérimental). Codex lance la revue sans commentaire @codex review lorsque l’événement associé à la merge request correspond à la politique et au déclencheur choisis.

La transmission des événements GitLab doit être activée via un webhook de projet ou celui d’un groupe ancêtre. Pour une instance GitLab autogérée ou GitLab Dedicated, le compte de service configuré doit également disposer d’un accès en écriture au projet. Codex utilise l’environnement de projet si vous en avez configuré un. Si la transmission des événements est déjà activée dans un groupe ancêtre, elle s’applique aussi aux projets qui en dépendent.

Personnalisez les vérifications effectuées par Codex

Codex recherche les fichiers AGENTS.md dans votre dépôt et suit les règles de revue de code applicables. Ajoutez une section ## Code Review Rules au fichier le plus proche du code concerné par ces règles. Si nécessaire, utilisez des titres de niveau ### pour regrouper les vérifications apparentées.

Par exemple, dans un service qui produit des rapports d’expérimentation, une règle peut empêcher qu’un comportement observé après l’exposition modifie la composition d’une cohorte de comparaison :

## Code Review Rules

### Cohortes expérimentales

- Lorsque vous comparez les traitements, ne filtrez pas les participants selon leur comportement après l’exposition, y compris la conversion ou la rétention.
  Constituez les cohortes à partir de l’affectation aux groupes ou de l’exposition. Présentez la conversion comme un résultat.

Placez les règles qui s’appliquent à tout le dépôt dans le fichier AGENTS.md à la racine et celles propres à un service dans un fichier situé dans un sous-répertoire, comme services/experiment_reporting/AGENTS.md. Pour chaque fichier modifié, Codex applique les consignes de la racine et les consignes plus spécifiques qui le concernent. Les changements sans rapport avec le service n’ont donc pas besoin de son contexte particulier.

Commencez par deux ou trois règles concises qui décrivent des vérifications que votre équipe explique souvent lors des revues. Pour rédiger des règles utiles :

• Ciblez les comportements propres au dépôt qui ont des conséquences importantes. Décrivez la contrainte de compatibilité, la limite à respecter dans le traitement des données ou l’effet de bord dangereux à signaler, et expliquez pourquoi.
• Précisez la marche à suivre ou l’exception prévue. Donnez à Codex assez de contexte pour distinguer un véritable problème d’un comportement attendu.
• Rédigez des règles ciblées et durables. Décrivez les résultats attendus plutôt que de citer des noms de fonctions susceptibles de changer. Placez les consignes près du code concerné.
• Confiez les vérifications mécaniques à la CI. Laissez le formatage, le lint et les autres vérifications déterministes en dehors des règles de revue.

Ouvrez une merge request représentative et demandez une revue avec @codex review. Affinez les règles en fonction des problèmes signalés et des retours reçus. Précisez la portée des consignes qui produisent des signalements inutiles ou supprimez-les.

Les règles de revue de code guident Codex. Elles ne remplacent ni les tests, ni les protections de branche, ni les approbations obligatoires.

Pour demander une vérification ponctuelle sur un sujet précis, indiquez-le dans votre commentaire sur la merge request :

@codex review recherchez les problèmes dans la migration de la base de données

Corrigez les problèmes signalés lors d’une revue

Pour que Codex corrige les problèmes signalés, le projet doit disposer d’un environnement de projet configuré. La transmission des événements du groupe suffit pour les revues, mais ne permet pas d’exécuter des tâches de développement. Si le projet dispose d’un environnement, demandez à Codex de corriger un problème en ajoutant un commentaire à la même merge request :

@codex corrigez le problème de priorité P1

Codex ouvre une discussion dans l’ancien environnement cloud en utilisant la merge request comme contexte et peut pousser un correctif vers la branche s’il dispose des droits nécessaires.

Confiez d’autres tâches à Codex

Les autres tâches de développement nécessitent également un environnement de projet configuré. La transmission des événements du groupe suffit pour les revues. Si vous mentionnez @codex dans un commentaire avec une instruction autre que review, Codex ouvre une discussion dans l’ancien environnement cloud en utilisant votre merge request comme contexte.

@codex corrigez les erreurs qui font échouer la CI

Résolvez les problèmes de revue de code

Si Codex ne réagit pas ou ne publie pas de revue :

• Vérifiez que vous avez sélectionné la bonne application GitLab. Si vous utilisez une configuration propre au projet, vérifiez que le projet dispose de l’environnement Codex Cloud prévu.
• Vérifiez que la transmission des événements est activée pour le projet ou un groupe ancêtre. Dans GitLab, ouvrez Webhooks → Événements récents et vérifiez que les événements liés aux merge requests et aux notes sont transmis avec succès.
• Pour une instance GitLab autogérée ou GitLab Dedicated, vérifiez que le webhook de projet ou de groupe est signé, que la vérification SSL est activée et que l’instance utilise GitLab 19.0 ou une version ultérieure. Sur une instance GitLab 19.0 autogérée, vérifiez que l’indicateur de fonctionnalité webhook_signing_token est activé. Remettez en état les webhooks désactivés automatiquement à la suite d’échecs.
• Pour une instance GitLab autogérée ou GitLab Dedicated, si vous utilisez un compte de service existant, vérifiez que son jeton d’accès personnel est actif et de portée api. Si Codex a créé le compte de service, vérifiez que celui-ci est correctement configuré dans les paramètres des connecteurs Codex et que la transmission des événements est activée pour le projet ou le groupe.
• Pour une instance GitLab autogérée ou GitLab Dedicated, vérifiez que le compte de service de l’espace de travail dispose lui-même du rôle Developer dans le projet ou un groupe parent afin que Codex puisse publier des revues et des réactions. Les droits de l’utilisateur GitLab connecté ne suffisent pas. Les projets héritent des droits liés à l’appartenance au groupe. La transmission des événements et les droits du compte de service se configurent séparément.
• Vérifiez que l’option Revue de code ou Revues automatiques est activée et que la merge request correspond à la politique du dépôt et au déclencheur choisis.
• Utilisez @codex review.