Gemini sur GitHub : reviews de PR et actions

Gemini peut faire la review de vos pull requests automatiquement : il lit le diff, commente en inline les lignes à risque et poste un résumé, le tout déclenché depuis GitHub Actions ou Cloud Build à chaque push. Cela transforme votre pipeline CI en reviewer de premier passage qui ne fatigue jamais et ne saute jamais les fichiers ennuyeux.

Cette leçon met tout ça en place de bout en bout. Vous verrez l'action officielle, un workflow YAML propre, les permissions exactes dont il a besoin, et les leviers qui le gardent peu coûteux et sûr.

Deux façons de faire tourner Gemini sur une PR

Il y a deux surfaces d'intégration distinctes, et les confondre fait perdre du temps.

Gemini Code Assist for GitHub est l'app managée. Vous l'installez depuis le GitHub Marketplace sur un repo ou une org, et elle fait la review des PR automatiquement, en plus de répondre aux commandes /gemini dans les commentaires. Pas de YAML, pas de gestion de clés. Commencez ici : Gemini Code Assist.

L'action Run Gemini CLI est la voie DIY. Vous contrôlez le workflow, le modèle, le prompt et les étapes exactes. C'est ce qu'il vous faut quand vous avez besoin de checks personnalisés (imposer une entrée de changelog, bloquer une dépendance, vérifier qu'un fichier de migration existe) ou quand vous voulez que la review tourne dans votre pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → Cloud Build existant. L'action est google-github-actions/run-gemini-cli.

Le reste de cette leçon se concentre sur la voie DIY, parce que c'est là que se trouve le contrôle « avancé ».

Ce que « le CLI en CI » veut dire concrètement

Vous connaissez déjà le Gemini CLI comme agent interactif de terminal. En CI, il tourne en headless : vous lui passez un prompt, il peut lire des fichiers et exécuter des outils shell (comme le CLI gh), puis il sort. La GitHub Action est un wrapper léger qui authentifie, alimente le CLI avec un prompt et lui donne les outils nécessaires pour poster des commentaires.

Le workflow de review de PR minimal

Voici un workflow complet et exécutable. Il se déclenche sur les pull requests, transmet le contexte du diff à Gemini, et laisse Gemini poster une review via le CLI GitHub.

name: Gemini PR Review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Gemini review
        uses: google-github-actions/run-gemini-cli@v0
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        with:
          gemini_model: gemini-2.5-flash
          prompt: |
            Review the diff for PR #${PR_NUMBER}.
            Run: gh pr diff ${PR_NUMBER}
            Focus on bugs, security issues, and missing error handling.
            Skip style nits. If the diff is clean, say so briefly.
            Post your review with:
            gh pr comment ${PR_NUMBER} --body "<your review>"

Remarquez ce qui n'est PAS là : pas de script personnalisé géant, pas d'appels APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → manuels. L'action authentifie le CLI, le prompt dit à Gemini quoi faire, et Gemini utilise gh (préinstallé sur les runners GitHub) pour lire le diff et répondre.

Pourquoi fetch-depth: 0

Un checkout shallow (le comportement par défaut) ne récupère que le commit de tête. gh pr diff a besoin d'assez d'historique pour calculer le diff par rapport à la branche de base. Récupérer tout l'historique évite une classe d'échecs « diff vide » qui ressemblent à un modèle ayant ignoré le code.

Permissions : donnez le minimum, nommez-le explicitement

Le bloc permissions est le contrôle de sécurité le plus important. GitHub n'accorde au GITHUB_TOKEN que ce que vous listez, rien de plus.

permissions:
  contents: read          # lire le code
  pull-requests: write    # poster des commentaires de review

C'est toute l'empreinte d'un job de review. Volontairement absents :

• contents: write (le job ne doit jamais pousser de code)
• actions: write (ne jamais modifier d'autres workflows)
• id-token: write (nécessaire seulement pour Workload Identity, voir plus bas)

Protégez-vous des PR issues de forks. Le trigger pull_request depuis un fork reçoit un tokentokenUn token est l'unité de base de texte que traitent les modèles de langage : le plus souvent un fragment de mot, un mot entier ou un signe de ponctuation, plutôt qu'un simple caractère.Voir la définition complète → en lecture seule et aucun accès à vos secrets, ce qui est correct et sûr. Si vous passez à pull_request_target pour obtenir l'accès aux secrets, vous exécutez désormais votre workflow avec des permissions d'écriture face à du code non fiable venant du fork. C'est un vecteur d'attaque bien connu. Préférez pull_request, et si un fork a réellement besoin d'une review, exigez qu'un mainteneur approuve l'exécution au préalable via le paramètre GitHub « require approval for outside collaborators ».

Authentification : clé API vs Vertex AI

Vous avez deux façons de fournir des credentials à l'action, et le choix affecte à la fois la facturation et la gouvernance.

Clé API Gemini (montrée plus haut). La plus simple. CrCrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éez une clé dans Google AI Studio, stockez-la comme secret de repo GEMINI_API_KEY. Bien pour les individus et les petites équipes. La facturation passe par l'API Gemini.

Vertex AI avec Workload Identity Federation. Pour les entreprises. Au lieu d'une clé à longue durée de vie, le workflow échange son token OIDC GitHub contre des credentials Google Cloud à courte durée de vie, donc il n'y a aucun secret à fuiter. Vous ajoutez id-token: write aux permissions et configurez l'étape google-github-actions/auth. La review tourne contre Vertex AI, ce qui veut dire qu'elle s'inscrit dans le projet Cloud, l'IAM, les quotas et l'audit logging de votre org. C'est la réponse quand la sécurité demande « où part notre code et qui peut le voir ».

Qualitativement : les clés démarrent plus vite, Vertex AI est ce sur quoi vous standardisez dès que plus de deux personnes en dépendent.

Garder ça peu coûteux

Les reviews automatisées tournent à chaque push. Sans limites, un contributeur bavard qui force-push dix fois peut déclencher dix reviews complètes. Trois leviers contrôlent le coût.

Choisissez le bon palier de modèle

Utilisez Gemini 2.5 Flash pour la review de PR de routine. C'est le palier rapide et peu coûteux, et il est largement capable de repérer des vérifications de null manquantes, des risques d'injection évidents et une gestion d'erreur absente. Réservez Gemini 2.5 Pro aux cas où vous avez besoin d'un raisonnement multi-fichiers plus profond, comme la review d'un refactoring architectural ou d'un changement de concurrence délicat. Un pattern courant : Flash par défaut, et un mainteneur peut taper /gemini review --deep pour relancer avec Pro à la demande.

Annulez les runs dépassés

Si quelqu'un pousse trois fois en une minute, ne faites la review que de la dernière version. Ajoutez un groupe de concurrency :

concurrency:
  group: gemini-review-${{ github.event.pull_request.number }}
  cancel-in-progress: true

À lui seul, ça peut réduire fortement la dépense sur les PR actives.

Cadrez ce que le modèle lit

Le long contexte est une force de Gemini, mais « pouvoir » n'est pas « devoir ». Injecter un monorepo entier dans chaque review est lent et coûteux. Contraignez le prompt au diff (gh pr diff), et pour les gros diffs, dites au modèle de se concentrer sur les fichiers les plus à risque (auth, migrations, logique de paiement) plutôt que de commenter chaque ligne modifiée. Vous pouvez aussi ignorer les fichiers générés et les lockfiles dans les instructions du prompt.

Au-delà de la review : labels, triage et checks bloquants

Une fois l'action en place, la review de PR n'est qu'un prompt parmi d'autres. Le même setup automatise les tâches fastidieuses de maintenance d'un repo.

Triage automatique des issues. Un workflow séparé déclenché sur issues: [opened] peut faire lire une nouvelle issue à Gemini, appliquer des labels (bug, docs, feature) et poster un commentaire « voilà ce qu'il nous faut pour reproduire ça ». Donnez-lui issues: write et rien d'autre.

Checks personnalisés bloquants. Comme le CLI peut exécuter des outils shell, vous pouvez lui demander d'imposer des règles projet qu'un linter n'exprime pas facilement. Exemple de ligne de prompt : « Si cette PR modifie un fichier sous db/migrations/, vérifie qu'un fichier de rollback correspondant existe. Sinon, poste un commentaire et sors avec le code 1. » Un code de sortie non nul fait échouer le check, ce qui peut bloquer le merge si vous en faites un status check requis dans la branch protection.

Maintenance planifiée. Un trigger schedule peut faire tourner Gemini chaque nuit pour résumer les PR dormantes ou signaler les dépendances qui ont dérivé. C'est là que la nature agentique du CLI paie : il lit l'état, raisonne et agit, en une seule étape.

Garder la review utile, pas bruyante

Le moyen le plus rapide de faire ignorer un bot est de le laisser commenter sur tout. Deux règles maintiennent un bon signal.

D'abord, dites-lui ce qu'il doit ignorer. Le style et le formatage appartiennent à votre linter et à votre formatter, pas à Gemini. Mettez « ne commente pas le formatage, l'ordre des imports ou le style de nommage » directement dans le prompt.

Une review de premier passage reste un premier passage, pas le mot final. Formulez le commentaire de résumé pour que les humains sachent qu'une machine l'a écrit. Un en-tête d'une ligne comme « Review automatisée par Gemini 2.5 Flash. L'approbation reste au humain. » pose les attentes et évite que la review soit prise pour une validation.

Un prompt qui vieillit bien

Stockez les instructions de review dans un fichier du repo (par exemple .gemini/review-prompt.md) et faites-le lire par le workflow, plutôt que d'intégrer un long prompt dans le YAML. Deux bénéfices : le prompt est versionné et reviewable comme n'importe quel autre code, et différents repos peuvent ajuster leurs propres priorités (un service critique en sécurité demande des checks plus stricts qu'un dashboard interne). L'action permet de pointer vers un fichier de settings exactement pour cette raison, ce qui garde votre workflow YAML court.

Le mettre dans Cloud Build

Si votre org fait tourner la CI dans Google Cloud plutôt que sur des runners GitHub, le même Gemini CLI tourne comme étape de Cloud Build. Vous déclenchez le build depuis un événement de PR GitHub, exécutez gemini dans une étape avec le prompt, et utilisez gh pour répondre. L'avantage, c'est que l'authentification à Vertex AI est native (le service account du build a déjà une identité Google Cloud), donc il n'y a pas de fédération OIDC à configurer et aucune clé à stocker. Pour les environnements régulés où le code ne peut pas quitter votre périmètre Cloud, c'est la topologie la plus propre.

Points clés

• Choisissez votre surface délibérément. Utilisez l'app GitHub managée Gemini Code Assist pour une review sans configuration ; utilisez l'action run-gemini-cli quand vous avez besoin de checks personnalisés, de prompts personnalisés ou d'une intégration Cloud Build.
• Cadrez les permissions au job. Un reviewer n'a besoin que de contents: read et pull-requests: write. N'accordez jamais d'accès en écriture au code, et évitez pull_request_target sur des forks non fiables.
• Flash par défaut, escalade vers Pro à la demande. Ajoutez un groupe concurrency avec cancel-in-progress et contraignez le prompt au diff pour garder un coût prévisible sur les PR actives.
• Authentifiez selon votre échelle. Commencez avec une clé API Gemini depuis AI Studio ; passez à Vertex AI avec Workload Identity Federation dès que la gouvernance, l'audit et la question « où part notre code » deviennent réels.
• Versionnez le prompt et étiquetez la sortie. Stockez les instructions de review dans le repo, dites au modèle ce qu'il doit ignorer, et marquez chaque commentaire comme automatisé pour qu'un humain garde la main sur le merge.