# Gemini on GitHub: PR Reviews and Actions
Gemini can review your pull requests automatically: it reads the diff, comments inline on risky lines, and posts a summary, all triggered inside GitHub Actions or Cloud Build on every push. This turns your CI pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → into a first-pass reviewer that never gets tired and never skips the boring files.
This lesson wires that up end to end. You will see the official action, a clean workflow YAML, the exact permissions it needs, and the levers that keep it cheap and safe.
There are two distinct integration surfaces, and mixing them up wastes time.
Gemini Code Assist for GitHub is the managed app. You install it from the GitHub Marketplace onto a repo or org, and it reviews PRs automatically plus responds to /gemini commands in comments. No YAML, no key management. Start here: Gemini Code Assist
The Run Gemini CLI action is the DIY path. You control the workflow, the model, the prompt, and the exact steps. This is what you want when you need custom checks (enforce a changelog entry, block a dependency, verify a migration file exists) or when you want the review to run inside your existing Cloud Build pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →. The action is google-github-actions/run-gemini-cli.
Rest of this lesson focuses on the DIY path, because that is where the "advanced" control lives.
You already know the Gemini CLI as an interactive terminal agent. In CI it runs headless: you pass it a prompt, it can read files and run shell tools (like the gh CLI), and it exits. The GitHub Action is a thin wrapper that authenticates, feeds the CLI a prompt, and gives it the tools it needs to post comments.
Here is a complete, runnable workflow. It triggers on pull requests, hands the diff context to Gemini, and lets Gemini post a review via the GitHub CLI.
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>"Notice what is NOT here: no giant custom script, no manual APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls. The action authenticates the CLI, the prompt tells Gemini what to do, and Gemini uses gh (preinstalled on GitHub runners) to read the diff and post back.
fetch-depth: 0A shallow checkout (the default) only grabs the tip commit. gh pr diff needs enough history to compute the diff against the base branch. Fetching full history avoids a class of "empty diff" failures that look like the model ignored the code.
The permissions block is the single most important safety control. GitHub grants the GITHUB_TOKEN only what you list, nothing more.
permissions:
contents: read # read the code
pull-requests: write # post review commentsThat is the whole footprint for a review job. Deliberately absent:
contents: write (the job must never push code)actions: write (never modify other workflows)id-token: write (only needed for Workload Identity, see below)Guard against forked PRs. The pull_request trigger from a fork gets a 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.View full definition → and no access to your secrets, which is correct and safe. If you switch to pull_request_target to get secret access, you are now running your workflow with write permissions against untrusted code from the fork. That is a well-known attack vector. Prefer pull_request, and if a fork genuinely needs review, require a maintainer to approve the run first via GitHub's "require approval for outside collaborators" setting.
You have two ways to give the action credentials, and the choice affects both billing and governance.
Gemini API key (shown above). Simplest. Create a key in Google AI Studio, store it as the GEMINI_API_KEY repo secret. Good for individuals and small teams. Billing runs through the Gemini APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →.
Vertex AI with Workload Identity Federation. For companies. Instead of a long-lived key, the workflow exchanges its 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.View full definition → for short-lived Google Cloud credentials, so there is no secret to leak. You add id-token: write to permissions and configure the google-github-actions/auth step. The review runs against Vertex AI, which means it lands under your org's Cloud project, IAM, quotas, and audit logging. This is the answer when security asks "where does our code go and who can see it."
Qualitatively: keys are faster to start, Vertex AI is what you standardize on once more than a couple of people depend on it.
Automated reviews run on every push. Without limits, a chatty contributor force-pushing ten times can trigger ten full reviews. Three levers control cost.
Use Gemini 2.5 Flash for routine PR review. It is the fast, low-cost tier and it is more than capable of spotting missing null checks, obvious injection risks, and absent error handling. Reserve Gemini 2.5 Pro for cases where you need deeper multi-file reasoning, like reviewing an architectural refactor or a tricky concurrency change. A common pattern: default to Flash, and let a maintainer type /gemini review --deep to re-run with Pro on demand.
If someone pushes three times in a minute, only review the latest. Add a concurrency group:
concurrency:
group: gemini-review-${{ github.event.pull_request.number }}
cancel-in-progress: trueThis alone can cut spend dramatically on active PRs.
Long context is a Gemini strength, but "can" is not "should." Feeding an entire monorepo into every review is slow and expensive. Constrain the prompt to the diff (gh pr diff), and for large diffs instruct the model to focus on the highest-risk files (auth, migrations, payment logic) rather than commenting on every changed line. You can also skip generated files and lockfiles in the prompt instructions.
Knowledge check
1. Why would a team choose the 'Run Gemini CLI' action over the managed Gemini Code Assist for GitHub app?
2. What does it mean that the Gemini CLI runs 'headless' in a CI pipeline?
3. What is the primary role of the GitHub Action wrapper around the Gemini CLI?
4. Select ALL correct answers about the two integration surfaces for running Gemini against a pull request.
Select all the correct answers.
5. Select ALL correct answers about what an automated Gemini PR reviewer can do in CI.
Select all the correct answers.
Once the action is in place, PR review is just one prompt. The same setup automates the tedious edges of maintaining a repo.
Auto-triage issues. A separate workflow triggered on issues: [opened] can have Gemini read a new issue, apply labels (bug, docs, feature), and post a "here is what we need to reproduce this" comment. Give it issues: write and nothing else.
Gated custom checks. Because the CLI can run shell tools, you can ask it to enforce project rules that a linter cannot easily express. Example prompt line: "If this PR changes any file under db/migrations/, verify a matching rollback file exists. If not, post a comment and exit with code 1." A nonzero exit fails the check, which can block merge if you make it a required status check in branch protection.
Scheduled maintenance. A schedule trigger can run Gemini nightly to summarize stale PRs or flag dependencies that drifted. This is where the CLI's agentic nature pays off: it reads state, reasons, and acts, all in one step.
The fastest way to get a bot ignored is to let it comment on everything. Two rules keep signal high.
First, tell it what to skip. Style and formatting belong to your linter and formatter, not to Gemini. Put "do not comment on formatting, import ordering, or naming style" directly in the prompt.
First-pass review means first pass, not final word. Frame the summary comment so humans know a machine wrote it. A one-line header like "Automated review by Gemini 2.5 Flash. A human still owns approval." sets expectations and prevents the review from being mistaken for a sign-off.
Store the review instructions in a file in the repo (for example .gemini/review-prompt.md) and have the workflow read it, rather than inlining a long prompt in YAML. Two benefits: the prompt is version-controlled and reviewable like any other code, and different repos can tune their own emphasis (a security-critical service asks for stricter checks than an internal dashboard). The action supports pointing at a settings file for exactly this reason, keeping your workflow YAML short.
If your org runs CI in Google Cloud rather than on GitHub runners, the same Gemini CLI runs as a Cloud Build step. You trigger the build from a GitHub PR event, run gemini in a step with the prompt, and use gh to post back. The advantage is that authentication to Vertex AI is native (the build's service account already has Google Cloud identity), so there is no OIDC federation to configure and no key to store at all. For regulated environments where code cannot leave your Cloud perimeter, this is the cleanest topology.
run-gemini-cli action when you need custom checks, custom prompts, or Cloud Build integration.contents: read and pull-requests: write. Never grant write access to code, and avoid pull_request_target on untrusted forks.concurrency group with cancel-in-progress and constrain the prompt to the diff to keep cost predictable on busy PRs.