Laisser un LLM relire nos pull requests (pour que vous n'ayez pas à le faire)

Nous aimons l’automatisation. Nous l’utilisons pour alimenter notre infrastructure, pour réduire les charges de travail à zéro, et — de plus en plus — pour diminuer la quantité d’attention humaine nécessaire pour livrer du code de haute qualité. Un domaine qui restait obstinément manuel était les revues de pull requests. Entre Cursor comme IDE, ChatGPT/Codex pour le prototypage, et gemini-cli pour des vérifications rapides, nos workflows locaux étaient rapides — mais le CI attendait encore un humain.

Nous nous sommes donc posé une question simple : pourrait-on laisser un grand modèle de langage lire le diff, repérer des problèmes et commenter directement la PR ?

Il s’avère que : oui. Il a suffi de quelques lignes de colle GitHub Actions pour obtenir des revues utiles et structurées sur chaque pull request.

L’objectif

Nous n’essayions pas de remplacer les humains. Nous voulions une première passe qui :

• lit le diff réel d’une PR (pas l’ensemble du dépôt),
• signale les erreurs évidentes et les changements risqués,
• suggère de petites refactorisations ou des tests manquants,
• classe les constats par priorité,
• et publie les résultats là où nous regardons déjà : dans la conversation de la PR et le résumé des Actions.

Si un changement est correct, nous voulons que le bot le dise simplement et se retire.

Les outils de notre stack

• GitHub Actions pour l’orchestration du CI.
• Cursor (notre IDE quotidien).
• ChatGPT/Codex pour l’idéation et des revues rapides hors ligne.
• @google/gemini-cli dans le CI pour exécuter l’étape de revue automatisée.
• La GitHub CLI (gh) pour commenter la PR.
• Un ingrédient petit mais important : un prompt qui oriente le modèle pour produire des retours utiles et actionnables.

Le workflow, de bout en bout

Voici l’Action complète que nous exécutons. Déposez-la dans .github/workflows/gemini-pr.yml:

name: gemini-pr
on:
  workflow_dispatch:
  pull_request:
jobs:
  build:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        submodules: 'true'
        fetch-depth: 0
    - uses: actions-rust-lang/setup-rust-toolchain@v1
      with:
        components: rustfmt, clippy
        cache: false
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - name: install gemini
      run: |
        npm install -g @google/gemini-cli
    - name: gemini
      run: |
        echo "merging into ${{ github.base_ref }}"
        git diff origin/${{ github.base_ref }} > pr.diff
        echo $PROMPT | gemini > review.md
        cat review.md >> $GITHUB_STEP_SUMMARY
        gh pr comment ${{ github.event.pull_request.number }} --body-file review.md
      env:
        GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        PROMPT: >
          please review the changes of @pr.diff (this pull request) and suggest improvements or provide insights into potential issues. 
          do not document or comment on existing changes, if everything looks good, just say so.
          can you categorise the changes and improvesments into low, medium and high priority?
          Whenever you find an issue, please always provide an file and line number as reference information. if multiple files are affected, please provide a list of files and line numbers.
          provide the output in markdown format and do not include any other text.

Ce que fait chaque partie

• Checkout avec fetch-depth: 0 afin de pouvoir faire un diff contre la branche de base de la PR de manière fiable.

• Chaîne d’outils Rust installe rustfmt et clippy parce que nos dépôts incluent souvent du code Rust ; ces outils s’exécutent ailleurs dans notre pipeline, mais conserver la configuration de la toolchain ici évite les surprises.

• Node est requis pour le gemini-cli.

• Nous installons @google/gemini-cli globalement à l’intérieur du runner.

• Nous créons un fichier diff :

  git diff origin/${{ github.base_ref }} > pr.diff
  

  Cela garantit que le modèle voit seulement les modifications à l’examen.

• Nous envoyons le prompt dans gemini (la CLI lit @pr.diff inline comme référence de fichier) et capturons la sortie Markdown du modèle dans review.md.

• Nous ajoutons la revue au Job Summary ($GITHUB_STEP_SUMMARY) pour qu’elle soit visible dans l’UI des Actions.

• Nous commentons la PR en utilisant gh pr comment … --body-file review.md.

Le prompt qui le rend utile

Les sorties des LLM ne sont aussi bonnes que les instructions. Le nôtre reste pratique :

• Portée : Ne revoir que ce qui a changé. Ne pas re-documenter le dépôt.
• Signal : Dire « Looks good. » quand il n’y a rien à ajouter. Pas de créativité forcée.
• Actionnabilité : Inclure toujours le fichier + numéros de ligne pour les constats.
• Priorités : Grouper par faible / moyen / élevé pour aider les relecteurs à parcourir rapidement.
• Format : Uniquement Markdown, afin que cela soit collé proprement dans les commentaires de PR et rendu correctement dans le résumé.

Nous avons itéré un peu pour parvenir à cela. Les ajustements les plus impactants ont été : insister sur les références fichier/ligne et interdire la prose superflue.

À quoi ressemble la revue

Sur une PR typique, nous voyons des sections comme :

• Élevé : changements sensibles pour la sécurité, gestion d’erreurs cassée, validation d’entrée manquante, secrets accidentels ou tests supprimés.
• Moyen : cas limites, risques de concurrence, messages d’erreur douteux, Rust/Go/TS non idiomatiques susceptibles de poser problème plus tard.
• Faible : nommage, commentaires, petites refactorisations, ou suggestion d’un test court pour verrouiller un comportement.

Si tout va bien, nous obtenons une ligne : « Looks good. » Parfait — c’est exactement ce que nous voulons.

Pièges et notes pratiques

• Secrets : Vous avez besoin de GEMINI_API_KEY et GITHUB_TOKEN dans les secrets du dépôt ou de l’organisation. Gardez les permissions réduites. L’Action définit permissions: write-all parce qu’elle publie un commentaire ; restreignez cela si votre politique l’exige.
• Source du diff : Pour les merges complexes, git diff origin/${{ github.base_ref }} donne le bon contexte. Si votre workflow ne récupère que le commit de merge, assurez-vous que la branche de base est disponible ou adaptez à github.event.pull_request.base.sha.
• Forks : Si vous acceptez des PR depuis des forks, examinez la façon dont vous gérez les secrets. Vous pourriez vouloir exécuter ceci sur pull_request_target avec un renforcement attentif, ou conditionner la revue à des labels.
• Contrôle du bruit : Nous avons trouvé utile de laisser le modèle ne rien dire au-delà de « Looks good. » quand un changement est trivial. Cela réduit la fatigue des relecteurs.
• Coûts et quotas : Les appels au modèle ne sont pas gratuits. Nous limitons la taille du diff envoyé et exécutons ceci seulement sur pull_request (pas à chaque push).
• Confidentialité : Vous envoyez votre diff à un fournisseur de modèle externe. Si votre code est sensible ou soumis à des restrictions d’exportation, évaluez le risque et choisissez un fournisseur/modèle de déploiement adapté à vos besoins de conformité.

Pourquoi c’est important (au-delà de la commodité)

Les revues automatisées rendent les humains plus sélectifs dans leur attention. Nous passons moins de temps sur « renommez cette variable » et plus de temps sur l’architecture, les flux de données et les frontières de sécurité. Cela signifie :

• Boucles de rétroaction plus rapides pour les contributeurs.
• Moins de cycles de revue pour des détails mineurs.
• Un historique de commits plus propre avec des problèmes détectés plus tôt.
• Plus de temps pour le travail de durabilité qui nous importe vraiment — comme réduire la consommation en watts d’un service ou diminuer l’egress réseau.

C’est aussi étonnamment bon en matière de cohérence. Un LLM n’oubliera pas le pattern de gestion d’erreurs convenu entre les services ni notre structure de logs préférée ; il applique ces vérifications de manière uniforme sur chaque PR.

Variantes que vous pouvez essayer

Ce schéma fonctionne avec presque n’importe quel modèle ou CLI. Quelques extensions faciles :

• Vote multi-modèle : Appeler deux modèles avec le même prompt et ne conserver que les constats sur lesquels ils s’accordent.
• Passes sensibles au langage : Si votre dépôt mélange les langages, lancez des prompts spécifiques par langage (par ex. un adapté à Rust avec des indices clippy, un pour TypeScript).
• « Fail on High » gates : Utiliser un petit parseur pour détecter une section « High » et basculer le job en failed pour bloquer les merges jusqu’à résolution.
• Revue en ligne : Convertir les références fichier/ligne en commentaires de revue GitHub (la CLI gh le supporte) pour un retour encore plus précis.
• Contrôle par label PR : N’exécuter que lorsqu’un mainteneur ajoute un label ai-review, ou ajouter automatiquement un label needs-attention quand des constats à haute priorité apparaissent.

Résultats à ce jour

• Cycles de revue plus courts sur les changements simples.
• Diffs plus propres car les contributeurs corrigent les points faciles avant qu’un humain ne regarde.
• Meilleure intégration : les nouveaux collègues reçoivent des conseils concrets qui reflètent ce que diraient les relecteurs seniors.
• Pas de drame : si le bot n’a rien à ajouter, il reste silencieux.

Rien de tout cela ne remplace un humain approuvant une fusion. C’est un filtre léger qui s’amortit dès le premier jour.