Documentation ChatGPT
Français
Contact goolvyouyou@gmail.com

Examiner les demandes de fusion GitLab avec Codex

Configurez Code Review pour les demandes de fusion GitLab et sollicitez des revues avec @codex review.

Utilisez la revue de code Codex pour bénéficier d’une nouvelle passe de revue très pertinente sur les demandes de fusion GitLab. Codex examine le diff de la demande de fusion, suit les consignes de votre dépôt et publie une revue de code GitLab standard axée sur les problèmes graves.

La prise en charge de GitLab est en version bêta et disponible avec tous les forfaits ChatGPT. L’intégration Codex s’exécute dans Codex cloud. Les contrôles de dépôt de type GitHub dans l’application de bureau, tels que Create pull request, ne sont pas inclus dans cette version bêta.

Avant de commencer

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

Configurer la revue de code Codex

Configurer la connexion GitLab et l’identité de revue Codex

Pour GitLab.com, connectez votre compte GitLab dans Codex une fois que vous avez connecté GitLab dans ChatGPT. Pour une instance GitLab autogérée ou Dedicated, chaque réviseur doit se connecter après la publication du modèle de l’administrateur de l’espace de travail.

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

Laisser Codex créer le compte

Dans Codex Cloud → Settings → Connectors, sélectionnez l’application correspondant à votre hôte GitLab autogéré ou Dedicated → sélectionnez Set up service account → Create a service account. L’administrateur de l’espace de travail qui termine la configuration doit disposer d’un accès administrateur à l’instance GitLab. Choisissez Selected groups ou Selected projects only, puis sélectionnez les emplacements où Codex doit intervenir et créez le compte. L’option de groupe accorde un accès Developer à chaque groupe choisi, hérité par ses projets et sous-groupes ; l’option de projet accorde un accès Developer uniquement aux projets individuels que vous sélectionnez. Codex crée le compte de service d’instance ChatGPT Codex Connector avec un jeton d’accès personnel doté de la portée api.

Utiliser un compte existant

Dans GitLab, créez ou choisissez un compte de service et accordez-lui un accès Developer uniquement dans les groupes ou projets où Codex doit intervenir. Sur la page Service accounts, sélectionnez le compte → Manage access tokens → Add new token afin de créer un jeton d’accès personnel avec la portée api et une date d’expiration distante d’au moins 30 jours. De retour dans Codex, choisissez Use an existing service account, collez le jeton, puis sélectionnez Save token. Le jeton est chiffré lors de son enregistrement et n’est plus jamais affiché.

Gérer le jeton du compte de service

Les administrateurs de l’espace de travail peuvent gérer le compte de service dans Codex Cloud → Settings → Connectors. Pour un compte créé par Codex, les administrateurs peuvent révoquer le jeton actuel et en générer un nouveau. Pour un compte existant, les administrateurs peuvent remplacer ou supprimer le jeton enregistré dans Codex et le révoquer séparément dans GitLab si nécessaire. Codex ne peut pas répondre à l’activité GitLab tant qu’un jeton valide n’est pas configuré.

Choisir comment l’activité GitLab parvient à Codex

Créer un environnement de projet pour les tâches de programmation ou une configuration propre au projet

Dans Codex Cloud → Settings → Environments, choisissez le projet GitLab et créez un environnement de projet lorsque vous souhaitez que Codex écrive ou exécute du code pour ce projet — par exemple, pour modifier des fichiers, valider des modifications ou envoyer des mises à jour vers une branche de demande de fusion — ou lorsqu’une revue dépend de secrets propres au projet, d’un accès réseau ou de commandes de configuration.

Pour GitLab.com, un environnement de projet est également requis afin d’activer les revues Codex.

Lors de la création de l’environnement, activez Enable Codex activity from GitLab pour installer le webhook de projet qui transmet à Codex les événements de demande de fusion, de commentaire et de ticket. La création du webhook de projet nécessite un accès Maintainer ou Owner, un accès administrateur ou un rôle personnalisé permettant 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 et a été supprimé dans GitLab 19.1.

Activer l’activité pour les revues Codex sur les projets d’un groupe GitLab

Pour une instance GitLab autogérée ou Dedicated, les administrateurs de l’espace de travail peuvent ouvrir Environments → GitLab activity → Manage groups afin d’activer les revues Codex dans un groupe et ses sous-groupes. Codex installe un webhook de groupe couvrant tous les projets de ce groupe. L’utilisateur GitLab connecté doit être Owner du groupe, et les webhooks de groupe nécessitent GitLab Premium ou Ultimate ainsi que GitLab 19.0 ou une version ultérieure.

L’activité de groupe active les revues de code, mais ne crée pas d’environnements de projet. Pour exécuter des tâches de programmation déclenchées par GitLab, comme modifier des fichiers, exécuter des commandes, valider des modifications ou envoyer des mises à jour vers une demande de fusion, créez un environnement de projet.

Configurer les politiques de revue de code

Configurez les politiques de revue de code dans les paramètres de revue Codex. Choisissez la politique du dépôt : Review my MRs, Review team MRs, Review all MRs ou Follow personal. Choisissez ensuite quand les revues s’exécutent : On MR open, On every push ou Smart Trigger (Experimental). Les paramètres du dépôt peuvent remplacer les valeurs personnelles par défaut.

Demander une revue Codex

  1. Dans un commentaire de demande de fusion, mentionnez @codex review.
  2. Attendez que Codex réagisse (👀) et publie une revue.

Codex publie des discussions et des notes GitLab sur la demande de fusion, comme le ferait un membre de l’équipe. Par défaut, les revues demandées manuellement peuvent inclure des constats P0, P1 et P2, tandis que les revues automatiques se concentrent sur les constats P0 et P1.

Activer les revues automatiques

Pour examiner automatiquement les demandes de fusion admissibles, activez Automatic reviews dans les paramètres Codex, choisissez la politique du dépôt GitLab, puis choisissez un déclencheur : On MR open, On every push ou Smart Trigger (Experimental). Codex s’exécute sans commentaire @codex review lorsque l’événement de demande de fusion correspond à cette politique et à ce déclencheur.

L’activité GitLab doit être activée au moyen d’un webhook de projet ou d’un webhook d’un groupe parent. Pour une instance GitLab autogérée ou Dedicated, le compte de service configuré doit également disposer d’un accès lui permettant de publier dans le projet. Codex utilise un environnement de projet configuré lorsqu’il existe. Si un groupe parent active déjà l’activité, les projets descendants héritent de cette couverture.

Personnaliser ce que Codex examine

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 régi par les règles. Utilisez des titres ### pour regrouper les vérifications associées lorsque cela est utile.

Par exemple, un service de génération de rapports d’expérimentation peut empêcher qu’un comportement postérieur à l’exposition modifie une cohorte de comparaison :

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

Placez les règles applicables à tout le dépôt dans le fichier AGENTS.md racine et les règles propres à un service dans un fichier imbriqué, tel que services/experiment_reporting/AGENTS.md. Codex applique les consignes racines et les consignes plus spécifiques qui couvrent chaque fichier modifié, afin que les modifications sans rapport n’aient pas à intégrer le contexte propre au service.

Commencez par deux ou trois règles concises qui codifient les vérifications souvent expliquées par les réviseurs. Règles utiles :

  • Concentrez-vous sur les comportements importants et propres au dépôt. Décrivez la contrainte de compatibilité, la limite de données ou l’effet secondaire dangereux à signaler, ainsi que son importance.
  • Indiquez la voie sûre ou l’exception. Donnez à Codex suffisamment de contexte pour distinguer un véritable problème d’un comportement attendu.
  • Gardez des règles ciblées et durables. Privilégiez les résultats plutôt que les noms de fonctions susceptibles de changer, et placez les consignes près du code qu’elles régissent.
  • Laissez les vérifications mécaniques à CI. Excluez des règles de revue le formatage, le lint et les autres vérifications déterministes.

Ouvrez une demande de fusion représentative et sollicitez une revue avec @codex review. Affinez les règles en fonction des constats et des retours observés, puis restreignez ou supprimez les consignes qui génèrent du bruit.

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

Pour une priorité ponctuelle, ajoutez-la au commentaire de votre demande de fusion :

@codex review for issues in the database migration

Traiter les constats de la revue

La correction des constats de la revue nécessite un environnement de projet configuré ; l’activité de groupe seule prend en charge les revues, mais ne peut pas exécuter de tâches de programmation. Si le projet dispose d’un environnement, demandez à Codex de corriger un problème dans la même demande de fusion en laissant un autre commentaire :

@codex fix the P1 issue

Codex démarre une conversation cloud avec la demande de fusion comme contexte et peut envoyer un correctif vers la branche lorsqu’il dispose des autorisations nécessaires.

Confier d’autres tâches à Codex

Les autres tâches de programmation nécessitent également un environnement de projet configuré ; l’activité de groupe seule prend en charge les revues. Si vous mentionnez @codex dans un commentaire contenant autre chose que review, Codex démarre une conversation cloud en utilisant votre demande de fusion comme contexte.

@codex fix the CI failures

Résoudre les problèmes de revue de code

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

  • Vérifiez que l’application GitLab prévue a été sélectionnée ; si vous utilisez une configuration propre au projet, vérifiez que celui-ci dispose de l’environnement Codex cloud prévu.
  • Vérifiez l’activité du projet ou d’un groupe parent. Dans GitLab, consultez Webhooks → Recent events et vérifiez que les demandes de fusion et les notes sont correctement transmises.
  • Pour une instance GitLab autogérée ou 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é ; réparez les hooks désactivés automatiquement après des échecs.
  • Pour une instance GitLab autogérée ou Dedicated, vérifiez qu’un jeton d’accès personnel de compte de service existant est actif et possède la portée api. Si Codex a créé le compte de service, vérifiez qu’il est correctement configuré dans les paramètres du connecteur Codex et que le projet ou le groupe est activé.
  • Pour une instance GitLab autogérée ou Dedicated, vérifiez que le compte de service de l’espace de travail — et pas uniquement l’utilisateur GitLab connecté — dispose d’un accès Developer au projet ou à un groupe parent, afin que Codex puisse publier des revues et des réactions. L’appartenance est héritée ; l’activité et l’accès du compte de service sont distincts.
  • Vérifiez que Code review ou Automatic reviews est activé et que la demande de fusion correspond à la politique et au déclencheur du dépôt.
  • Utilisez @codex review.