Gemini auf GitHub: PR-Reviews und Actions

# Gemini auf GitHub: PR-Reviews und Actions

Gemini kann Ihre Pull Requests automatisch reviewen: Es liest den Diff, kommentiert riskante Zeilen inline und postet eine Zusammenfassung, ausgelöst innerhalb von GitHub Actions oder Cloud Build bei jedem Push. Damit wird Ihre CI-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → zum First-Pass-Reviewer, der nie müde wird und nie die langweiligen Dateien überspringt.

Diese Lektion baut das von Anfang bis Ende auf. Sie sehen die offizielle Action, ein sauberes Workflow-YAML, die genau benötigten Permissions und die Stellschrauben, die das Ganze günstig und sicher halten.

Zwei Wege, Gemini gegen einen PR laufen zu lassen

Es gibt zwei getrennte Integrationsflächen, und sie zu verwechseln kostet Zeit.

Gemini Code Assist for GitHub ist die managed App. Sie installieren sie aus dem GitHub Marketplace auf ein Repo oder eine Org, und sie reviewt PRs automatisch und reagiert zusätzlich auf /gemini-Befehle in Kommentaren. Kein YAML, kein Key-Management. Hier starten: Gemini Code Assist.

Die Run Gemini CLI Action ist der DIY-Weg. Sie steuern den Workflow, das Modell, den Prompt und die genauen Schritte. Das brauchen Sie, wenn Sie eigene Checks benötigen (Changelog-Eintrag erzwingen, eine Dependency blocken, prüfen ob eine Migrationsdatei existiert) oder wenn das Review in Ihrer bestehenden Cloud-Build-PipelinePipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Vollständige Definition ansehen → laufen soll. Die Action heißt google-github-actions/run-gemini-cli.

Der Rest dieser Lektion konzentriert sich auf den DIY-Weg, denn dort liegt die „fortgeschrittene“ Kontrolle.

Was „die CLI in CI“ konkret bedeutet

Sie kennen die Gemini CLI bereits als interaktiven Terminal-Agenten. In CI läuft sie headless: Sie übergeben ihr einen Prompt, sie kann Dateien lesen und Shell-Tools ausführen (etwa die gh CLI), und dann beendet sie sich. Die GitHub Action ist ein dünner Wrapper, der authentifiziert, der CLI einen Prompt gibt und ihr die Tools bereitstellt, die sie zum Posten von Kommentaren braucht.

Der minimale PR-Review-Workflow

Hier ein vollständiger, lauffähiger Workflow. ErErThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → triggert bei Pull Requests, übergibt den Diff-Kontext an Gemini und lässt Gemini ein Review über die GitHub CLI posten.

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>"

Beachten Sie, was hier NICHT steht: kein riesiges eigenes Skript, keine manuellen APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Calls. Die Action authentifiziert die CLI, der Prompt sagt Gemini, was zu tun ist, und Gemini nutzt gh (auf GitHub-Runnern vorinstalliert), um den Diff zu lesen und zurückzuschreiben.

Warum fetch-depth: 0

Ein Shallow Checkout (der Standard) holt nur den Tip-Commit. gh pr diff braucht genug History, um den Diff gegen den Base-Branch zu berechnen. Die volle History zu holen vermeidet eine Klasse von „leerer Diff“-Fehlern, die so aussehen, als hätte das Modell den Code ignoriert.

Permissions: so wenig wie möglich, explizit benannt

Der permissions-Block ist die wichtigste einzelne Sicherheitskontrolle. GitHub gibt dem GITHUB_TOKEN nur das, was Sie auflisten, sonst nichts.

permissions:
  contents: read          # read the code
  pull-requests: write    # post review comments

Das ist der gesamte Footprint für einen Review-Job. Bewusst nicht enthalten:

• contents: write (der Job darf niemals Code pushen)
• actions: write (niemals andere Workflows verändern)
• id-token: write (nur für Workload Identity nötig, siehe unten)

Vorsicht bei geforkten PRs. Der pull_request-Trigger aus einem Fork bekommt ein Read-only-TokenTokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Vollständige Definition ansehen → und keinen Zugriff auf Ihre Secrets, was korrekt und sicher ist. Wenn Sie auf pull_request_target wechseln, um Secret-Zugriff zu bekommen, läuft Ihr Workflow mit Write-Permissions gegen nicht vertrauenswürdigen Code aus dem Fork. Das ist ein bekannter Angriffsvektor. Bevorzugen Sie pull_request, und wenn ein Fork tatsächlich ein Review braucht, verlangen Sie über GitHubs Einstellung „require approval for outside collaborators“, dass ein Maintainer den Run zuerst freigibt.

Authentifizierung: APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Key vs. Vertex AI

Sie haben zwei Wege, der Action Credentials zu geben, und die Wahl betrifft sowohl Billing als auch Governance.

Gemini API-Key (oben gezeigt). Am einfachsten. Erstellen Sie einen Key im Google AI Studio und speichern Sie ihn als Repo-Secret GEMINI_API_KEY. Gut für Einzelpersonen und kleine Teams. Die Abrechnung läuft über die Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →.

Vertex AI mit Workload Identity Federation. Für Unternehmen. Statt eines langlebigen Keys tauscht der Workflow sein GitHub-OIDC-TokenTokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.Vollständige Definition ansehen → gegen kurzlebige Google-Cloud-Credentials, es gibt also kein Secret, das leaken kann. Sie fügen id-token: write zu den Permissions hinzu und konfigurieren den Schritt google-github-actions/auth. Das Review läuft gegen Vertex AI, landet also im Cloud-Projekt Ihrer Org, mit deren IAM, Quotas und Audit Logging. Das ist die Antwort, wenn Security fragt: „Wohin geht unser Code und wer kann ihn sehen?“

Qualitativ: Keys sind schneller startklar, Vertex AI ist das, worauf Sie standardisieren, sobald mehr als eine Handvoll Leute davon abhängen.

Kosten niedrig halten

Automatische Reviews laufen bei jedem Push. Ohne Limits kann ein gesprächiger Contributor, der zehnmal force-pusht, zehn vollständige Reviews auslösen. Drei Stellschrauben steuern die Kosten.

Die richtige Modellstufe wählen

Nutzen Sie Gemini 2.5 Flash für Routine-PR-Reviews. Das ist die schnelle, günstige Stufe und sie erkennt problemlos fehlende Null-Checks, offensichtliche Injection-Risiken und fehlendes Error Handling. Reservieren Sie Gemini 2.5 Pro für Fälle, in denen Sie tieferes Reasoning über mehrere Dateien brauchen, etwa beim Review eines architektonischen Refactorings oder einer kniffligen Concurrency-Änderung. Ein verbreitetes Muster: standardmäßig Flash, und ein Maintainer kann /gemini review --deep tippen, um bei Bedarf mit Pro erneut zu laufen.

Überholte Runs abbrechen

Wenn jemand dreimal in einer Minute pusht, reviewen Sie nur den letzten Stand. Fügen Sie eine Concurrency Group hinzu:

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

Allein das kann die Ausgaben bei aktiven PRs drastisch senken.

Begrenzen, was das Modell liest

Langer Kontext ist eine Stärke von Gemini, aber „kann“ heißt nicht „soll“. Ein ganzes Monorepo in jedes Review zu füttern ist langsam und teuer. Beschränken Sie den Prompt auf den Diff (gh pr diff), und weisen Sie das Modell bei großen Diffs an, sich auf die risikoreichsten Dateien zu konzentrieren (Auth, Migrationen, Payment-Logik), statt jede geänderte Zeile zu kommentieren. Sie kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen in den Prompt-Anweisungen auch generierte Dateien und Lockfiles ausschließen.

Über das Review hinaus: Labeling, Triage und gated Checks

Sobald die Action steht, ist das PR-Review nur ein Prompt. Dasselbe Setup automatisiert die lästigen Randbereiche der Repo-Pflege.

Issues automatisch triagieren. Ein separater Workflow mit Trigger auf issues: [opened] kann Gemini ein neues Issue lesen lassen, Labels vergeben (bug, docs, feature) und einen Kommentar posten nach dem Muster „das brauchen wir, um das zu reproduzieren“. Geben Sie ihm issues: write und sonst nichts.

Gated Custom Checks. Weil die CLI Shell-Tools ausführen kann, kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen Sie sie Projektregeln durchsetzen lassen, die ein Linter nur schwer ausdrücken kann. Beispielzeile im Prompt: „Wenn dieser PR eine Datei unter db/migrations/ ändert, prüfe, ob eine passende Rollback-Datei existiert. Falls nicht, poste einen Kommentar und beende mit Code 1.“ Ein Exit-Code ungleich null lässt den Check fehlschlagen, was den Merge blockieren kann, wenn Sie ihn im Branch Protection als Required Status Check setzen.

Geplante Wartung. Ein schedule-Trigger kann Gemini nachts laufen lassen, um veraltete PRs zusammenzufassen oder abgedriftete Dependencies zu markieren. Hier zahlt sich die agentische Natur der CLI aus: Sie liest State, denkt nach und handelt, alles in einem Schritt.

Das Review nützlich halten, nicht laut

Der schnellste Weg, dass ein Bot ignoriert wird, ist ihn alles kommentieren zu lassen. Zwei Regeln halten das Signal hoch.

Erstens: Sagen Sie ihm, was ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → überspringen soll. Style und Formatierung gehören zu Ihrem Linter und Formatter, nicht zu Gemini. Schreiben Sie „kommentiere nicht zu Formatierung, Import-Reihenfolge oder Namensstil“ direkt in den Prompt.

First-Pass-Review heißt First Pass, nicht letztes Wort. Formulieren Sie den Summary-Kommentar so, dass Menschen wissen, dass eine Maschine ihn geschrieben hat. Eine einzeilige Kopfzeile wie „Automatisches Review von Gemini 2.5 Flash. Die Freigabe liegt weiterhin bei einem Menschen.“ setzt die Erwartungen und verhindert, dass das Review mit einem Sign-off verwechselt wird.

Ein Prompt, der gut altert

Legen Sie die Review-Anweisungen in einer Datei im Repo ab (zum Beispiel .gemini/review-prompt.md) und lassen Sie den Workflow sie lesen, statt einen langen Prompt inline im YAML zu führen. Zwei Vorteile: Der Prompt ist versioniert und reviewbar wie jeder andere Code, und verschiedene Repos kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →önnen ihre eigenen Schwerpunkte setzen (ein sicherheitskritischer Service verlangt strengere Checks als ein internes Dashboard). Die Action unterstützt genau deshalb den Verweis auf eine Settings-Datei und hält Ihr Workflow-YAML kurz.

Umsetzung in Cloud Build

Wenn Ihre Org CI in Google Cloud statt auf GitHub-Runnern betreibt, läuft dieselbe Gemini CLI als Cloud-Build-Step. Sie triggern den Build aus einem GitHub-PR-Event, führen gemini in einem Step mit dem Prompt aus und nutzen gh, um zurückzuschreiben. Der Vorteil: Die Authentifizierung gegen Vertex AI ist nativ (der Service Account des Builds hat bereits eine Google-Cloud-Identität), es gibt also keine OIDC-Federation zu konfigurieren und überhaupt keinen Key zu speichern. Für regulierte Umgebungen, in denen Code Ihren Cloud-Perimeter nicht verlassen darf, ist das die sauberste Topologie.

Key Takeaways

• Wählen Sie Ihre Integrationsfläche bewusst. Nutzen Sie die managed Gemini Code Assist GitHub App für Review ohne Konfiguration; nutzen Sie die run-gemini-cli Action, wenn Sie eigene Checks, eigene Prompts oder Cloud-Build-Integration brauchen.
• Permissions auf den Job zuschneiden. Ein Reviewer braucht nur contents: read und pull-requests: write. Geben Sie nie Schreibzugriff auf Code und vermeiden Sie pull_request_target bei nicht vertrauenswürdigen Forks.
• Standard ist Flash, Eskalation auf Pro bei Bedarf. Fügen Sie eine concurrency Group mit cancel-in-progress hinzu und beschränken Sie den Prompt auf den Diff, damit die Kosten bei viel befahrenen PRs planbar bleiben.
• Authentifizieren Sie passend zu Ihrer Größe. Starten Sie mit einem Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Vollständige Definition ansehen →-Key aus dem AI Studio; wechseln Sie zu Vertex AI mit Workload Identity Federation, sobald Governance, Audit und „wohin geht unser Code“ echte Fragen werden.
• Versionieren Sie den Prompt und kennzeichnen Sie den Output. Legen Sie Review-Anweisungen im Repo ab, sagen Sie dem Modell, was es überspringen soll, und markieren Sie jeden Kommentar als automatisiert, damit der Merge weiterhin einem Menschen gehört.