name: Code Review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
permissions:
pull-requests: write
contents: read
issues: write
jobs:
code-review:
runs-on: ubuntu-latest
# Automatisierte Code-Reviews für Entwurfs-PRs überspringen
if: github.event.pull_request.draft == false
steps:
- name: Repository auschecken
uses: actions/checkout@v4
with:
fetch-depth: 0
ref: ${{ github.event.pull_request.head.sha }}
- name: Cursor-CLI installieren
run: |
curl https://cursor.com/install -fsS | bash
echo "$HOME/.cursor/bin" >> $GITHUB_PATH
- name: Git-Identität konfigurieren
run: |
git config user.name "Cursor Agent"
git config user.email "cursoragent@cursor.com"
- name: Automatisiertes Code-Review durchführen
env:
CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
MODEL: gpt-5
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
BLOCKING_REVIEW: ${{ vars.BLOCKING_REVIEW || 'false' }}
run: |
cursor-agent --force --model "$MODEL" --output-format=text --print 'Du arbeitest in einem GitHub-Actions-Runner und führst ein automatisiertes Code-Review durch. Die gh-CLI ist verfügbar und über GH_TOKEN authentifiziert. Du darfst Pull Requests kommentieren.
Kontext:
- Repo: ${{ github.repository }}
- PR Number: ${{ github.event.pull_request.number }}
- PR Head SHA: ${{ github.event.pull_request.head.sha }}
- PR Base SHA: ${{ github.event.pull_request.base.sha }}
- Blockierendes Review: ${{ env.BLOCKING_REVIEW }}
Ziele:
1) Bestehende Review-Kommentare erneut prüfen und mit resolved antworten, wenn erledigt.
2) Den aktuellen PR-Diff prüfen und nur eindeutige, schwerwiegende Probleme markieren.
3) Sehr kurze Inline-Kommentare (1–2 Sätze) ausschließlich auf geänderten Zeilen hinterlassen und am Ende eine kurze Zusammenfassung.
Vorgehen:
- Bestehende Kommentare abrufen: gh pr view --json comments
- Diff abrufen: gh pr diff
- Geänderte Dateien mit Patches abrufen, um Inline-Positionen zu berechnen: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/files --paginate --jq '.[] | {filename,patch}'
- Exakte Inline-Anker für jedes Problem berechnen (Dateipfad + Diff-Position). Kommentare MÜSSEN inline auf der geänderten Zeile im Diff platziert werden, nicht als Top-Level-Kommentare.
- Frühere Top-Level-Kommentare im Stil „keine Probleme“ erkennen, die von diesem Bot verfasst wurden (Texte wie: "✅ no issues", "No issues found", "LGTM").
- Wenn beim aktuellen Lauf Probleme gefunden werden und frühere „keine Probleme“-Kommentare existieren:
- Diese nach Möglichkeit entfernen, um Verwirrung zu vermeiden:
- Versuchen, Top-Level-Kommentare zu löschen via: gh api -X DELETE repos/${{ github.repository }}/issues/comments/<comment_id>
- Falls Löschen nicht möglich ist, via GraphQL minimieren (minimizeComment) oder so bearbeiten, dass "[Superseded by new findings]" vorangestellt wird.
- Falls weder Löschen noch Minimieren möglich ist, auf diesen Kommentar antworten: "⚠️ Superseded: issues were found in newer commits".
- Wenn ein zuvor gemeldetes Problem durch nahe Änderungen behoben erscheint, antworte: ✅ This issue appears to be resolved by the recent changes
- NUR analysieren auf:
- Null/undefined-Dereferenzierungen
- Ressourcenlecks (nicht geschlossene Dateien oder Verbindungen)
- Injection (SQL/XSS)
- Nebenläufigkeit/Race Conditions
- Fehlende Fehlerbehandlung bei kritischen Operationen
- Offensichtliche Logikfehler mit fehlerhaftem Verhalten
- Klare Performance-Anti-Patterns mit messbarem Einfluss
- Eindeutige Sicherheitslücken
- Duplikate vermeiden: überspringen, wenn ähnliches Feedback bereits auf oder nahe derselben Zeile existiert.
Kommentarregeln:
- Maximal 10 Inline-Kommentare insgesamt; priorisiere die kritischsten Probleme
- Ein Problem pro Kommentar; exakt auf der geänderten Zeile platzieren
- Alle Problemkommentare MÜSSEN inline sein (an Datei und Zeile/Position im PR-Diff verankert)
- Natürlicher Ton, spezifisch und umsetzbar; nicht erwähnen, dass es automatisiert ist oder auf hoher Sicherheit beruht
- Emojis verwenden: 🚨 Kritisch 🔒 Sicherheit ⚡ Performance ⚠️ Logik ✅ Behoben ✨ Verbesserung
Einreichung:
- Wenn es KEINE Probleme zu melden gibt und bereits ein bestehender Top-Level-Kommentar vorhanden ist, der „keine Probleme“ angibt (z. B. "✅ no issues", "No issues found", "LGTM"), KEINEN weiteren Kommentar einreichen. Einreichung überspringen, um Redundanz zu vermeiden.
- Wenn es KEINE Probleme zu melden gibt und KEIN vorheriger „keine Probleme“-Kommentar existiert, einen kurzen Zusammenfassungskommentar einreichen, der keine Probleme vermerkt.
- Wenn es Probleme zu melden gibt und ein vorheriger „keine Probleme“-Kommentar existiert, sicherstellen, dass der vorherige Kommentar vor Einreichung des neuen Reviews gelöscht/minimiert/als überholt markiert wird.
- Wenn es Probleme zu melden gibt, EIN Review einreichen, das NUR Inline-Kommentare plus einen optionalen knappen Zusammenfassungstext enthält. Die GitHub-Reviews-API verwenden, um sicherzustellen, dass Kommentare inline sind:
- Ein JSON-Array von Kommentaren erstellen wie: [{ "path": "<file>", "position": <diff_position>, "body": "..." }]
- Einreichen via: gh api repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/reviews -f event=COMMENT -f body="$SUMMARY" -f comments='[$COMMENTS_JSON]'
- NICHT verwenden: gh pr review --approve oder --request-changes
Blockierendes Verhalten:
- Wenn BLOCKING_REVIEW true ist und irgendein 🚨- oder 🔒-Problem gepostet wurde: echo "CRITICAL_ISSUES_FOUND=true" >> $GITHUB_ENV
- Andernfalls: echo "CRITICAL_ISSUES_FOUND=false" >> $GITHUB_ENV
- CRITICAL_ISSUES_FOUND immer am Ende setzen
'
- name: Ergebnisse des blockierenden Reviews prüfen
if: env.BLOCKING_REVIEW == 'true'
run: |
echo "Prüfe auf kritische Probleme..."
echo "CRITICAL_ISSUES_FOUND: ${CRITICAL_ISSUES_FOUND:-unset}"
if [ "${CRITICAL_ISSUES_FOUND:-false}" = "true" ]; then
echo "❌ Kritische Probleme gefunden und blockierendes Review ist aktiviert. Workflow wird fehlgeschlagen."
exit 1
else
echo "✅ Keine blockierenden Probleme gefunden."
fi
