Laisser un LLM examiner 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 à zéro la charge de travail, et—de plus en plus—pour diminuer l’attention humaine requise pour livrer du code de haute qualité. Un domaine qui restait obstinément manuel était les revues de pull-request. Entre Cursor comme IDE, ChatGPT/Codex pour le prototypage, et gemini-cli pour des vérifications rapides, nos flux de travail locaux étaient rapides—mais l’intégration continue attendait toujours un humain.

Alors nous avons posé une question simple : pourrait-on laisser un grand modèle de langage lire le diff, détecter les problèmes, et commenter directement sur 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.

The goal

Nous ne voulions pas remplacer les humains. Nous voulions un premier passage qui :

• lise le diff réel d’une PR (pas tout le repo),
• pointe les erreurs évidentes et les changements risqués,
• suggère des petits refactors ou des tests manquants,
• catégorise les constats par priorité,
• et publie les résultats juste là où nous regardons déjà : dans la conversation de la PR et le résumé des Actions.

Si un changement est bon, nous voulons que le bot le dise simplement et se fasse discret.

The tools in our stack

• GitHub Actions pour l’orchestration 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.
• Le GitHub CLI (gh) pour commenter la PR.
• Un ingrédient petit mais important : un prompt qui guide le modèle pour produire des retours utiles et exploitables.

The workflow, end to end

Voici l’Action complète que nous utilisons. Placez-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.

What each part does

• Checkout avec fetch-depth: 0 afin que nous puissions diff contre la branche de base de la PR de manière fiable.

• Toolchain Rust installe rustfmt et clippy car nos repos incluent souvent du code Rust ; ceux-ci tournent ailleurs dans notre pipeline, mais configurer la toolchain ici évite les surprises.

• Node est requis pour le gemini-cli.

• Nous installons @google/gemini-cli globalement dans le runner.

• Nous créons un fichier diff :

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

  Cela garantit que le modèle voit seulement les changements soumis à revue.

• Nous piped le prompt dans gemini (le CLI lit @pr.diff inline comme référence fichier) et capturons la sortie markdown dans review.md.

• Nous ajoutons la revue au Résumé du Job ($GITHUB_STEP_SUMMARY) pour qu’elle soit visible dans l’UI Actions.

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

The prompt that makes it useful

Les sorties LLM ne valent que par les consignes. Les nôtres restent pragmatiques :

• Portée : Ne revoir que ce qui a changé. Ne pas redocumenter le dépôt.
• Signal : Dire “looks good” lorsqu’il n’y a rien à ajouter. Pas de créativité forcée.
• Actionnabilité : Inclure toujours fichier + numéro de ligne pour chaque constat.
• Priorités : Grouper par basse / moyenne / haute pour faciliter le balayage par les reviewers.
• Format : Markdown uniquement, pour que cela se colle proprement dans les commentaires de PR et s’affiche bien dans le résumé.

Nous avons un peu itéré pour en arriver là. Les ajustements les plus impactants étaient : exiger les références fichier/ligne et interdire le texte additionnel.

What the review looks like

Sur une PR typique, nous voyons des sections comme :

• High : Changements sensibles à la sécurité, gestion d’erreurs cassée, validation d’input manquante, secrets accidentels, ou tests supprimés.
• Medium : Cas-limite, risques de concurrence, messages d’erreur douteux, Rust/Go/TS non idiomatiques qui pourraient poser problème plus tard.
• Low : Nommage, commentaires, petits refactors, ou suggestion d’un test court pour verrouiller un comportement.

Si tout est bon, on reçoit une ligne : “Looks good.” Parfait—c’est exactement ce que nous voulons.

Gotchas and practical notes

• Secrets : Vous avez besoin de GEMINI_API_KEY et GITHUB_TOKEN dans les secrets du repo ou org. Gardez les périmètres serrés. L’Action définit permissions: write-all car elle poste un commentaire ; restreignez si votre politique le demande.
• 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 soit accessible ou adaptez à github.event.pull_request.base.sha.
• Forks : Si vous acceptez des PRs de forks, examinez la gestion des secrets. Vous pouvez vouloir exécuter ceci sur pull_request_target avec un durcissement rigoureux, 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 considérablement la fatigue des reviewers.
• Coûts et quotas : Les appels au modèle ne sont pas gratuits. Nous limitons la taille du diff envoyé et exécutons cela seulement sur pull_request (pas à chaque push).
• Vie privée : Vous envoyez votre diff à un fournisseur de modèle externe. Si votre code est sensible ou soumis à des restrictions d’export, évaluez les risques et choisissez un fournisseur/déploiement conforme à vos exigences.

Why this matters (beyond convenience)

Les revues automatisées rendent les humains plus sélectifs dans leur attention. Nous passons moins de temps sur “renommer cette variable” et plus sur l’architecture, les flux de données, et les périmètres de sécurité. Cela signifie :

• Boucles de feedback plus rapides pour les contributeurs.
• Moins de cycles de revue pour les petits détails.
• Un historique de commit plus propre avec les 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 d’énergie d’un service ou diminuer le trafic réseau sortant.

C’est aussi étonnamment efficace en termes de cohérence. Un LLM ne va pas oublier le modèle de gestion d’erreur convenu entre services ni notre structure de logs préférée ; il applique ces vérifications uniformément sur chaque PR.

Variations you might try

Ce modèle fonctionne avec presque tous les modèles ou CLI. Quelques extensions faciles :

• Vote multi-modèles : Appeler deux modèles avec le même prompt et ne garder que les constats sur lesquels ils s’accordent.
• Passes sensibles aux langages : Si votre repo mélange des langages, exécutez des prompts spécifiques à chaque langue (ex. un ajusté pour Rust avec conseils clippy, un pour TypeScript).
• Gates “Fail on High” : Utilisez un petit parseur pour détecter une section “High” et passer le job à failed pour bloquer les merges jusqu’à correction.
• Revue inline : Convertir les références fichier/ligne en commentaires de revue GitHub (le CLI gh supporte cela) pour un retour encore plus ciblé.
• Contrôle par label PR : N’exécuter que quand un mainteneur ajoute un label ai-review, ou ajouter automatiquement un label needs-attention en cas de constats haute priorité.

Results so far

• Cycles de revue plus courts sur les changements simples.
• Diffs plus propres car les contributeurs corrigent les points faciles avant que l’humain ne regarde.
• Meilleure intégration : les nouveaux coéquipiers reçoivent des conseils concrets reflétant le feedback attendu des reviewers seniors.
• Pas de drame : si le bot n’a rien à ajouter, il reste silencieux.

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