Gemini CLI sur GitHub et en CI

Vous pouvez faire lire à Gemini chaque pull request ouverte par votre équipe, lui faire laisser une review structurée, et ne jamais ouvrir un onglet de navigateur. C'est la promesse de Gemini CLI exécuté dans GitHub Actions : le même CLI agentique que vous utilisez en local, désormais déclenché par des événements du dépôt et encadré par les garde-fous que vous définissez.

Cette leçon porte sur la mise en place correcte. Pas une démo qui poste « looks good to me », mais un reviewer qui tourne en CI, respecte le moindre privilège et échoue bruyamment quand quelque chose ne va pas.

Pourquoi le CLI, et pas seulement Code Assist

Vous connaissez déjà Gemini Code Assist, le compagnon dans l'IDE qui complète le code et répond à vos questions dans l'éditeur. Il vit là où un humain tape.

Gemini CLI se distingue sur un point qui compte ici : c'est un agent headless et scriptable. Il lit des fichiers, exécute des outils et produit une sortie depuis une ligne de commande. Tout ce qui peut exécuter un shell, y compris un runner de CI, peut l'exécuter. C'est exactement ce que GitHub Actions vous donne : une machine Linux éphémère qui démarre sur un événement comme pull_request.

L'architecture est donc simple. Une PR s'ouvre. GitHub démarre un runner. Le runner installe Gemini CLI, lui passe le diff et un prompt, et le CLI appelle l'API Gemini (Flash ou Pro selon la charge du job) et écrit une review sur la PR.

La voie officielle : la GitHub Action

Google publie une GitHub Action maintenue pour que vous n'ayez pas à scripter l'installation vous-même. La configuration canonique se trouve dans le dépôt google-github-actions/run-gemini-cli. Elle encapsule le CLI, gère l'authentification et expose le prompt et les outils comme inputs du workflow.

Deux façons de vous authentifier :

• Une clé d'API Gemini depuis Google AI Studio, stockée comme secret GitHub. Le plus rapide pour démarrer.
• Vertex AI avec Workload Identity Federation si vous êtes sur Google Cloud et voulez une auth sans clé rattachée à un service account. C'est la voie entreprise, et elle évite totalement les secrets à longue durée de vie. Voir Vertex AI pour le volet plateforme.

Pour un dépôt d'équipe, préférez la seconde. Pour un projet de week-end, la clé d'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 → suffit.

Un workflow qui review chaque pull request

Voici un workflow complet et exécutable. Il se déclenche à l'ouverture ou à la mise à jour d'une PR, exécute Gemini CLI avec un prompt de review ciblé, et est verrouillé par les réglages de permissions et de concurrence que j'explique juste après.

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

permissions:
  contents: read
  pull-requests: write

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

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

      - name: Gemini code review
        uses: google-github-actions/run-gemini-cli@v0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          gemini_api_key: ${{ secrets.GEMINI_API_KEY }}
          prompt: |
            Review the diff for this pull request. Focus only on:
            correctness bugs, security issues, and missing error handling.
            Skip style nits. For each finding, cite the file and line.
            If you find nothing serious, say so in one sentence.

C'est tout. L'action run-gemini-cli fait le gros du travail : elle lit le contexte de la PR, exécute le modèle sur votre prompt et poste le résultat en commentaire via le GITHUB_TOKEN.

Quelques choix délibérés dans ce fichier méritent qu'on s'y arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête.

Pourquoi fetch-depth: 0

Par défaut, actions/checkout fait un clone superficiel avec seulement le dernier commit. Un reviewer qui ne voit pas le diff face à la branche de base ne sert à rien. fetch-depth: 0 récupère tout l'historique pour que le CLI puisse calculer et raisonner sur les changements réels.

Le prompt est une spec, pas un souhait

Remarquez que le prompt nomme exactement trois catégories et dit explicitement au modèle d'ignorer les remarques de style. C'est le plus gros levier sur la qualité des reviews. Un prompt vague (« review cette PR ») produit des commentaires bruyants et peu fiables que votre équipe coupera en une semaine. Un prompt cadré produit du signal.

Traitez le prompt comme une checklist de code review que vous donneriez à une nouvelle recrue. Nommez ce qui compte, nommez ce qu'il faut ignorer, et exigez des citations pour qu'un humain puisse vérifier chaque affirmation.

Garde-fousGarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → : la partie que les gens sautent

Un modèle qui peut commenter des PR est à peu près inoffensif. Un modèle qui peut exécuter des outils arbitraires, pousser des commits ou lire vos secrets, non. La CI est précisément l'endroit où une configuration bâclée devient un incident. Voici les garde-fous qui comptent, par ordre de priorité.

1. Permissions au moindre privilège

Le bloc permissions du workflow est votre premier mur. Dans beaucoup d'organisations, le GITHUB_TOKEN par défaut est bien plus puissant que ce dont un reviewer a besoin.

permissions:
  contents: read
  pull-requests: write

contents: read permet à l'action de lire le code. pull-requests: write lui permet de commenter. Rien d'autre. Le job ne peut pas pousser sur des branches, ni modifier des workflows, ni toucher aux releases. Si une prompt injection dans une PR malveillante tentait de pousser l'agent plus loin, le token n'a simplement pas la portée nécessaire.

2. Le problème des forks

C'est celui qui piège les équipes. L'événement pull_request venant d'un dépôt forké s'exécute avec 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 sans accès aux secrets, par conception, pour qu'un attaquant ne puisse pas ouvrir une PR qui exfiltre votre GEMINI_API_KEY.

Il existe une alternative tentante, pull_request_target, qui s'exécute dans le contexte du dépôt de base et a accès aux secrets. Ne la dégainez pas à la légère pour « réparer » les reviews sur les forks. Exécuter du code de PR non fiable avec accès à vos secrets est le piège classique de GitHub Actions. Si vous devez supporter les forks, conditionnez le job à un déclencheur manuel labeled pour qu'un mainteneur examine le diff avant toute exécution privilégiée.

3. Figez le modèle et plafonnez le coût

Choisissez votre palier de modèle en conscience. Pour l'essentiel du travail de review de PR, Gemini Flash est le bon choix : rapide, peu coûteux, et largement capable de repérer les problèmes de correction et de sécurité dans un diff. Réservez Gemini Pro aux jobs qui exigent un raisonnement profond sur plusieurs fichiers, comme la review architecturale d'une grosse branche de feature.

Combinez cela avec timeout-minutes sur le job et la concurrence **cancel-in-progress (pour qu'un force-push n'empile pas trois reviews sur une même PR) et votre dépense reste prévisible**.

4. Le modèle conseille, il ne décide pas

Gardez la review sous forme de commentaire, pas de status check obligatoire qui bloque les merges, au moins au début. Un reviewer LLMLLMUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → est une paire d'yeux supplémentaire, pas une barrière. Si vous le promouvez plus tard en check bloquant, cadrez ce check étroitement (par exemple, n'échouer que sur les findings que le modèle qualifie de critiques pour la sécurité) et conservez une voie de contournement humaine.

Au-delà de la review : triage, labels et slash commands

La review de PR est le premier usage évident, mais la même action fait plus.

Triage des issues sur une planification

Pointez un workflow planifié vers vos issues ouvertes et demandez au CLI de les labelliser et de les prioriser. Le prompt fait la classification, et la permission issues: write lui permet d'appliquer les labels. C'est réellement utile sur un dépôt actif où les issues non triées s'accumulent pendant la nuit.

Aide à la demande via une mention

Vous pouvez déclencher l'action sur issue_comment et la faire répondre quand quelqu'un écrit @gemini-cli suivi d'une question. Un contributeur demande « pourquoi ce test échoue-t-il sur Windows ? » dans un commentaire, le workflow se déclenche, et Gemini répond en ligne avec le contexte du dépôt.

Le schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → est toujours le même : un événement déclenche le runner, un prompt cadré plus les bonnes permissions définissent ce que l'agent peut faire, et la sortie repart vers GitHub. Une fois cette boucle intériorisée, vous pouvez construire n'importe lequel de ces cas en une après-midi.

Instructions personnalisées avec GEMINI.md

Un prompt valable pour tout le dépôt, c'est bien. Un prompt qui connaît vos conventions, c'est mieux. Gemini CLI lit un fichier GEMINI.md depuis votre dépôt comme contexte permanent, exactement comme en local. Déposez-en un à la racine et le reviewer en CI hérite de vos règles maison sans que vous les entassiez dans le YAML du workflow.

# Project review guidelines

- This is a TypeScript monorepo. Flag any use of `any`.
- All database calls must go through `src/db/client.ts`. Flag direct queries.
- Public API changes require a changeset file. Flag PRs that add endpoints without one.
- Never suggest disabling ESLint rules to make a check pass.

Votre prompt de review peut désormais rester court et générique, parce que la connaissance spécifique au projet vit dans le contrôle de version, à côté du code qu'elle régit. Quand les conventions changent, vous modifiez GEMINI.md dans une PR normale, et le reviewer qui review cette PR suit déjà les nouvelles règles.

Cette séparation compte : le workflow définit la *capacité* (ce que l'agent est autorisé à faire), et GEMINI.md définit la *politique* (à quoi ressemble le bon code dans cette base). Gardez-les distincts.

D'abord en local, ensuite en CI

Une habitude de travail vous évitera beaucoup d'exécutions Actions en échec : développez le prompt en local avant de le committer. Exécutez d'abord Gemini CLI sur votre machine contre une vraie branche.

git checkout feature/payment-retry
gemini -p "Review the diff against main. Focus on correctness, \
security, and error handling. Cite file and line for each finding."

Itérez sur la formulation jusqu'à ce que la sortie soit vraiment utile. Ensuite seulement, collez ce prompt dans le workflow. La CI est un endroit lent et inconfortable pour déboguer la formulation d'un prompt, parce que chaque modification est un commit et une exécution de plusieurs minutes. Votre laptop est instantané.

Points clés

• Utilisez l'action officielle. Branchez google-github-actions/run-gemini-cli dans un workflow pull_request plutôt que de scripter l'installation du CLI vous-même, et préférez Vertex AI avec Workload Identity Federation à une clé d'API à longue durée de vie pour les dépôts d'équipe.
• Cadrez le prompt comme une checklist. Nommez les quelques points que le reviewer doit attraper et dites-lui explicitement d'ignorer le reste. Un prompt focalisé fait la différence entre un reviewer de confiance et du bruit que votre équipe coupe.
• Verrouillez les permissions. N'accordez que contents: read et pull-requests: write, ne recourez jamais à pull_request_target pour supporter les forks sans un contrôle par un mainteneur, et gardez la review en commentaire, pas en barrière bloquant le merge, jusqu'à ce que vous lui fassiez confiance.
• Choisissez le palier en conscience. Par défaut Gemini Flash pour la review de diff et la maîtrise des coûts ; passez à Pro uniquement pour du raisonnement profond sur plusieurs fichiers.
• Mettez la politique dans `GEMINI.md`. Gardez les conventions du projet dans un fichier versionné pour que le workflow reste générique et que vos règles vivent à côté du code, et testez toujours les prompts en local avant de les committer en CI.