Laisser un LLM examiner nos Pull Requests (pour que vous n’ayez pas à le faire)

Nous adorons l’automatisation. Nous l’utilisons pour alimenter notre infrastructure, réduire les charges à zéro, et — de plus en plus — diminuer l’attention humaine nécessaire pour livrer un code de haute qualité. Une étape qui restait encore très manuelle était la revue des 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 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, repérer les problèmes, et commenter directement sur la PR ?

Finalement : oui. Quelques lignes de glue GitHub Actions ont suffi pour obtenir des revues utiles et structurées à chaque pull request.

The goal

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

• lit le diff réel d’une PR (et non le repo complet),
• signale les erreurs évidentes et changements risqués,
• suggère de petites refactorisations ou tests manquants,
• catégorise les résultats par priorité,
• et poste les résultats là où nous regardons déjà : dans la conversation PR et dans le résumé des Actions.

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

The tools in our stack

• GitHub Actions pour orchestrer le 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 crucial : un prompt qui guide le modèle pour produire un retour utile et exploitable.

The workflow, end to end

Voici l’Action complète que nous exécutons. 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 pour pouvoir comparer correctement avec la base de la PR.

• Toolchain Rust installe rustfmt et clippy car nos repos contiennent souvent du Rust ; ces outils s’exécutent ailleurs dans la pipeline, mais configurer ici évite les surprises.

• Node est requis pour 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
  

  Ceci garantit que le modèle voit seulement les changements en revue.

• Nous pipedons 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 via gh pr comment … --body-file review.md.

The prompt that makes it useful

Les sorties LLM sont aussi bonnes que les instructions. La nôtre reste pragmatique :

• Scope : Ne revoir que ce qui change. 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.
• Actionability : Inclure toujours fichier + numéro de ligne pour les problèmes détectés.
• Priorities : Grouper par faible / moyen / élevé pour faciliter la lecture.
• Format : Markdown uniquement, pour un collage propre dans les commentaires PR et un rendu net dans le résumé.

Nous avons itéré un peu pour atteindre ce résultat. Les ajustements les plus impactants furent : insister sur les références fichier/ligne et interdire tout texte superflu.

What the review looks like

Sur une PR typique, on voit des sections comme :

• High : changements sensibles en sécurité, gestion d’erreur cassée, validations d’entrée manquantes, secrets accidentels, ou tests supprimés.
• Medium : cas limites, risques de concurrence, messages d’erreur douteux, Rust/Go/TS non idiomatique pouvant poser problème plus tard.
• Low : nommage, commentaires, petits refactors, ou suggestion d’un test court pour verrouiller un comportement.

Si tout va bien, on a 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 repo ou org. Gardez les scopes serrés. L’Action met permissions: write-all car elle poste un commentaire ; restreignez si votre politique l’exige.
• Source du diff : Pour des merges complexes, git diff origin/${{ github.base_ref }} donne le contexte correct. Si votre workflow récupère seulement le commit de merge, assurez-vous que la branche de base est disponible ou ajustez avec github.event.pull_request.base.sha.
• Forks : Si vous acceptez des PR de forks, vérifiez la gestion des secrets. Vous pouvez vouloir exécuter ceci sur pull_request_target avec des protections strictes, ou verrouiller la revue derrière des labels.
• Gestion du bruit : Il est utile de laisser le modèle ne rien dire autre que « looks good » si le changement est trivial. Cela réduit la fatigue des reviewers.
• Coûts et quotas : Les appels modèle ne sont pas gratuits. Nous plafonnons la taille du diff envoyé et n’exécutons cela que sur pull_request (pas à chaque push).
• Confidentialité : Vous envoyez votre diff à un fournisseur externe. Si votre code est sensible ou soumis à restrictions d’export, évaluez les risques et choisissez un fournisseur ou une configuration conforme.

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 frontières de sécurité. Cela signifie :

• Des boucles de retours plus rapides pour les contributeurs.
• Moins de cycles de revue sur des détails mineurs.
• Un historique de commits plus propre avec des problèmes détectés plus tôt.
• Plus de temps pour des travaux durables qui comptent vraiment — comme réduire la consommation d’énergie d’un service ou diminuer le trafic réseau sortant.

C’est aussi étonnamment bon en cohérence. Un LLM n’oubliera pas le pattern convenu de gestion d’erreur entre services ni notre structure de logs préférée ; il applique ces règles uniformément à chaque PR.

Variations you might try

Ce pattern fonctionne avec presque tous les modèles ou CLI. Quelques extensions simples :

• Vote multi-modèles : interroger deux modèles avec le même prompt et garder uniquement les résultats sur lesquels ils s’accordent.
• Passes par langue : si votre repo mélange les langages, lancez des prompts spécifiques (ex. un adapté à Rust avec des indices clippy, un autre pour TypeScript).
• Gates « Fail on High » : utilisez un petit parser pour détecter une section « High » et passer le job en échec pour bloquer les merges tant que non corrigé.
• Revue inline : convertir les références fichier/ligne en commentaires de revue GitHub (le CLI gh le permet) pour un retour encore plus ciblé.
• Contrôle par labels PR : ne lancer que quand un mainteneur ajoute un label ai-review, ou ajouter automatiquement un label needs-attention si des problèmes haute priorité sont trouvés.

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 reçoivent des conseils concrets qui reflètent ce qu’un reviewer senior dirait.
• Pas de drame : si le bot n’a rien à ajouter, il reste silencieux.

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