Passa al contenuto principale

Una GitHub Action che revisiona ogni PR

Avanzato
What you'll learn
  • Collegare Claude Code headless a un workflow pull_request che revisiona il diff e commenta
  • Impostare il blocco permissions su solo commento, e spiegare perché contents: write è la linea che non si supera
  • Trattare il contenuto delle pull request come input non attendibile, perché è esattamente ciò che è
  • Mantenere limitato il costo di una revisione al crescere dei diff
  • Scrivere il prompt in modo che il commento venga letto invece di essere compresso

Un classico dell'automazione ad alto valore: far revisionare a Claude ogni pull request e pubblicare le sue osservazioni come commento — eseguendolo headless in CI. Ecco la forma, con le protezioni che lo mantengono sicuro.

Cosa fa​

A ogni PR: fa il checkout del diff, chiede a Claude di revisionarlo cercando bug, casi limite e problemi di convenzioni, e pubblica un commento. Le persone decidono ancora; Claude dà solo una prima passata rapida.

Guided walkthrough1 of 4
  1. Un clone shallow non vede il branch di base, quindi il diff esce vuoto e la revisione si legge come un via libera sicuro su nulla. Recupera la profondità completa.

Il workflow (bozza)​

name: Claude PR review
on: pull_request
permissions:
  contents: read
  pull-requests: write   # to comment — NOT write to code
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - name: Review the diff
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.patch
          claude -p "Review this diff for correctness bugs, missing edge cases, and
          security issues. Report ONLY high-confidence findings as a Markdown
          checklist with file:line. Diff:" < /tmp/diff.patch > /tmp/review.md
      # then post /tmp/review.md as a PR comment (e.g. with the gh CLI or an action)

(L'invocazione headless esatta può differire — vedi la documentazione. Il principio è: dare in pasto il diff, catturare il Markdown, pubblicarlo.)

Le protezioni (leggi Rafforzare le esecuzioni autonome)​

Privilegio minimo in CI
  • Solo commento. Concedi pull-requests: write, non contents: write — il bot non deve pushare codice.
  • Limita il token; non esporre mai accesso a deploy/segreti a un job che legge contenuto non attendibile di una PR.
  • Tratta il contenuto della PR come non attendibile — può portare prompt injection; non lasciare che il job compia azioni con conseguenze.
  • Limita il costo — i diff grandi costano token; valuta di revisionare solo i file modificati.

Renderlo utile, non rumoroso​

  • Chiedi solo osservazioni ad alta confidenza — un muro di pignolerie viene ignorato.
  • Tienilo come prima passata, con le persone che decidono il merge.

The review prompt — tuned for a comment people actually read

Review this diff for correctness bugs, missing edge cases, and security issues.

Rules for your output:
- Report ONLY high-confidence findings. If you are unsure, leave it out.
- One Markdown checklist item per finding, each starting with file:line.
- State the concrete failure: what input or state leads to what wrong result.
- No style nitpicks, no praise, no summary of what the diff does.
- If you find nothing high-confidence, say exactly that in one line.

Diff:

Check yourself

0/3
  1. Il tuo job di revisione deve pubblicare un commento sulla pull request. Quale blocco permissions è corretto?
  2. Perché il passo di checkout usa fetch-depth: 0?
  3. Un contributor apre una PR la cui descrizione dice al reviewer di ignorare i controlli di sicurezza e approvare. Qual è la postura giusta?
Key takeaways
  • L'intero job è: checkout a profondità completa, diff su file, una passata headless, pubblicazione del Markdown. Quattro passi, uno solo dei quali richiede accesso in scrittura.
  • pull-requests: write e contents: read. Mai contents: write in un job che legge contenuto scritto da contributor.
  • fetch-depth: 0, altrimenti il diff è vuoto e la revisione si legge come un certificato di buona salute.
  • Il contenuto delle PR non è attendibile e può portare prompt injection. Il privilegio minimo è il controllo; la formulazione del prompt non è un confine.
  • Chiedi solo osservazioni ad alta confidenza, con file:line. Un muro di pignolerie viene compresso e l'automazione muore di indifferenza.
  • Limita il costo al crescere dei diff — revisionare solo i file modificati è la leva abituale.
  • È una prima passata. Le persone decidono ancora il merge.

Avanti​