Verwendung von Bugbot für automatisierte Code-Überprüfung in Cursor

Bugbot ist Cursors integrierter Agent für automatisierte Code-Überprüfung, der sich direkt in Ihre GitHub-Repositories integriert. Wenn Sie einen Pull Request öffnen, analysiert Bugbot den Diff, identifiziert potenzielle Bugs, schlägt Verbesserungen vor und hinterlässt Inline-Kommentare zu Ihrem PR. Dieser Leitfaden behandelt alles von der Ersteinrichtung bis zur erweiterten Konfiguration, einschließlich PR-Routing- und GitHub Teams-Integrationsprobleme, auf die Forumsbenutzer häufig stoßen.
Was Bugbot tut
Bugbot führt mehrere Analyseebenen für jeden Pull Request durch:
- Bug-Erkennung - Identifiziert Logikfehler, Null-Referenz-Risiken und Randfälle
- Sicherheits-Scan - Markiert potenzielle Schwachstellen wie SQL-Injection oder fest codierte Secrets
- Stil und Konsistenz - Prüft auf Abweichungen von Ihren Codebase-Mustern
- Leistungshinweise - Hebt ineffiziente Muster wie N+1-Abfragen hervor
- Testabdeckung - Vermerkt, wenn Änderungen keine entsprechenden Tests haben
Bugbot läuft vollständig in der Cloud. Sie müssen Cursor nicht geöffnet lassen, damit Überprüfungen stattfinden. Nach der Aktivierung für ein Repository überprüft Bugbot jeden PR automatisch, unabhängig davon, ob Sie an Ihrem Schreibtisch sind oder nicht.
Voraussetzungen
Bevor Sie Bugbot einrichten, stellen Sie sicher, dass Sie haben:
- Cursor Pro oder Business-Plan - Bugbot ist in der kostenlosen Version nicht verfügbar
- Ein GitHub-Repository mit aktivierten Pull-Request-Workflows
- Admin- oder Maintainer-Zugriff auf das Repository (für die App-Installation erforderlich)
- GitHub Teams konfiguriert, wenn Sie teambasiertes PR-Routing wünschen
Aktivieren von Bugbot in einem Repository
Das am häufigsten von Forumsbenutzern gemeldete Problem ist, dass Bugbot "disabled for this repository" anzeigt. Dies lässt sich fast immer auf einen übersprungenen oder unvollständig abgeschlossenen GitHub-App-Installationsschritt zurückverfolgen.
Schritt 1: Cursor GitHub-App installieren
Bugbot arbeitet über eine GitHub-App. Wenn Sie diese noch nicht installiert haben:
- Öffnen Sie Cursor und navigieren Sie zu Settings > Features > Bugbot
- Klicken Sie auf Connect GitHub Account
- Sie werden zu GitHub weitergeleitet, um die Cursor-App zu autorisieren
- Wählen Sie den Umfang:
- All repositories - Cursor kann jedes Repo in Ihrem Konto überprüfen
- Selected repositories - Wählen Sie bestimmte Repos für die Überprüfung
Wenn Sie bei der Installation bestimmte Repositories ausgewählt haben und später ein neues Repository erstellen, wird Bugbot nicht für das neue Repo funktionieren, bis Sie es explizit hinzufügen. Dies ist die häufigste Ursache für den Fehler "disabled for this repository". Um ihn zu beheben, gehen Sie zu GitHub > Settings > Integrations > Applications > Cursor > Configure und fügen Sie das neue Repository hinzu.
Schritt 2: Bugbot in Cursor-Einstellungen aktivieren
Nachdem die GitHub-App installiert wurde:
- Öffnen Sie Cursor Settings (
Cmd/Ctrl + ,) - Navigieren Sie zu Features > Bugbot
- Schalten Sie Enable Bugbot auf ON
- Wählen Sie die Repositories, auf denen Bugbot aktiviert werden soll
Schritt 3: Verbindung verifizieren
Erstellen Sie einen Test-Pull-Request und prüfen Sie, ob Bugbot antwortet:
# Create a test branch
git checkout -b test-bugbot-connection
# Make a small change
echo "// Bugbot test" >> README.md
git add README.md
git commit -m "test: verify bugbot connection"
git push origin test-bugbot-connection
Öffnen Sie einen PR auf GitHub. Innerhalb von 30-60 Sekunden sollte Bugbot einen Kommentar posten. Wenn nicht, fahren Sie mit dem Abschnitt zur Fehlerbehebung unten fort.
PR-Routing und Reviewer-Zuweisung
Bugbot kann Pull Requests basierend auf Dateipfaden, Code-Eigentum oder Teammitgliedschaft an bestimmte Reviewer weiterleiten. Forumsbenutzer berichten, dass PR-Routing nicht immer wie erwartet funktioniert, insbesondere bei GitHub Teams.
PR-Routing verstehen
PR-Routing bestimmt, wer die Überprüfungsanfrage erhält, wenn Bugbot einen PR analysiert. Die Routing-Logik folgt dieser Priorität:
- CODEOWNERS-Datei - Falls vorhanden, werden die Eigentümer der geänderten Dateien zu Reviewern
- GitHub Teams-Mapping - Team-basiertes Routing über Bugbot-Konfiguration
- Fallback - Alle Maintainer erhalten die Überprüfungsanfrage
CODEOWNERS konfigurieren
Erstellen Sie eine CODEOWNERS-Datei im Repository-Root (oder .github/CODEOWNERS):
# Default owners
* @team-leads
# Frontend files
src/components/ @frontend-team
src/pages/ @frontend-team
src/styles/ @frontend-team
# Backend files
src/api/ @backend-team
src/models/ @backend-team
src/middleware/ @backend-team
# Infrastructure
terraform/ @devops-team
docker/ @devops-team
.github/workflows/ @devops-team
# Security-sensitive files
src/auth/ @security-team @team-leads
.env* @security-team
GitHub Teams-Integration
Für teambasiertes Routing liest Bugbot Ihre GitHub Teams-Mitgliedschaft. Zum Konfigurieren:
- Stellen Sie sicher, dass Ihre GitHub-Organisation Teams unter Org Settings > Teams eingerichtet hat
- Fügen Sie Mitglieder zu jedem Team hinzu
- Referenzieren Sie Teamnamen (mit
@-Präfix) in CODEOWNERS - Gehen Sie in Cursor zu Settings > Features > Bugbot > Advanced
- Aktivieren Sie Use GitHub Teams for routing
GitHub-Teamnamen in CODEOWNERS müssen genau übereinstimmen. Ein häufiger Fehler ist die Verwendung von Anzeigenamen anstelle des Team-Slugs. Wenn Ihr Team beispielsweise "Frontend Engineers" heißt mit dem Slug frontend-engineers, muss der CODEOWNERS-Eintrag @frontend-engineers lauten, nicht @Frontend Engineers.
Häufige PR-Routing-Probleme
Problem: PR an falsches Team weitergeleitet
Symptom: Ein PR, der Backend-Dateien ändert, wird an das Frontend-Team weitergeleitet.
Ursache: Überlappende CODEOWNERS-Muster. Das erste übereinstimmende Muster gewinnt, und Muster werden von oben nach unten ausgewertet.
Lösung: Ordnen Sie Ihre CODEOWNERS-Datei so an, dass spezifischere Muster vor allgemeinen stehen:
# Specific first
src/auth/ @security-team @team-leads
src/api/ @backend-team
# Then general
src/ @all-developers
* @team-leads
Problem: Team erhält keine Überprüfungsanfragen
Symptom: Bugbot überprüft den PR, aber es werden keine GitHub-Teammitglieder als Reviewer hinzugefügt.
Ursache: Das GitHub-Team ist auf "secret" (nicht sichtbar) gesetzt oder hat keine Mitglieder.
Lösung: Gehen Sie zu GitHub > Organization > Teams > [Teamname] > Settings. Stellen Sie sicher, dass die Teamsichtbarkeit nicht auf "Secret" gesetzt ist, wenn das Team Überprüfungsanfragen erhalten soll. Überprüfen Sie, dass das Team aktive Mitglieder hat.
Bugbot-Konfiguration
Über die grundlegende Aktivierung hinaus bietet Bugbot mehrere Konfigurationsoptionen zur Anpassung seines Verhaltens.
Überprüfungsstreng
Kontrollieren Sie, wie streng Bugbot bei seinen Ergebnissen ist:
{
"bugbot.severity": "balanced",
"bugbot.maxComments": 20,
"bugbot.autoResolve": false
}
| Streng | Verhalten |
|---|---|
| strict | Meldet alle Ergebnisse, einschließlich kleinerer Stilprobleme |
| balanced | Meldet Bugs, Sicherheitsprobleme und signifikante Stilprobleme (Standard) |
| lenient | Meldet nur Bugs und Sicherheitslücken |
Datei-Ausschlüsse
Verhindern Sie, dass Bugbot generierte oder vendorte Dateien überprüft:
{
"bugbot.excludePaths": [
"**/*.min.js",
"**/*.min.css",
"node_modules/**",
"dist/**",
"build/**",
"*.lock",
"package-lock.json",
"yarn.lock"
]
}
Sicherheitsagent-Konfiguration
Bugbot enthält einen dedizierten Sicherheitsagenten, der nach Schwachstellen scannt. Konfigurieren Sie ihn unabhängig:
{
"bugbot.securityAgent": {
"enabled": true,
"sensitivityLevel": "high",
"scanForSecrets": true,
"scanForDependencies": true,
"ignorePatterns": [
"test/**",
"__mocks__/**"
]
}
}
Der Sicherheitsagent scannt nach fest codierten Secrets (API-Schlüssel, Passwörter, Token) in Ihrem PR-Diff. Wenn er findet, was er für ein Secret hält, wird er es als kritisches Problem markieren. Dies ist eine Sicherheitsfunktion. Ignorieren Sie diese Warnungen niemals, ohne zu überprüfen, ob die markierte Zeichenfolge kein echtes Secret ist. Selbst Test-Fixtures, die wie echte Schlüssel aussehen, können gefährlich sein, wenn jemand sie in Produktionscode kopiert.
Genehmigungsworkflows
Bugbot integriert sich mit dem Überprüfungs- und Genehmigungssystem von GitHub. Sie können konfigurieren, ob Bugbots Ergebnisse das Zusammenführen von PRs blockieren.
Erforderliche Reviews festlegen
In Ihren GitHub-Repository-Einstellungen:
- Gehen Sie zu Settings > Branches > Branch protection rules
- Bearbeiten Sie die Regel für Ihren Hauptbranch
- Unter Require pull request reviews before merging:
- Legen Sie die erforderlichen Genehmigungen fest (z.B. 2)
- Aktivieren Sie Dismiss stale pull request approvals wenn neue Commits gepusht werden
- Aktivieren Sie Require review from Code Owners
Bugbot als erforderlichen Reviewer
Sie können Bugbot als erforderlichen Reviewer konfigurieren. Wenn aktiviert, können PRs nicht zusammengeführt werden, bis Bugbot seine Überprüfung abgeschlossen und entweder genehmigt hat oder die Überprüfung zurückgewiesen wurde.
In Cursor:
- Settings > Features > Bugbot > Workflow
- Aktivieren Sie Block merge on critical findings
- Legen Sie den Schweregrad-Schwellenwert für die Blockierung fest (Standard: critical und high)
Verwenden Sie die Blockierungsfunktion mit Bedacht. Wenn Sie den Schwellenwert zu niedrig ansetzen (Blockierung bei Ergebnissen mit geringer Schwere), können Entwickler frustriert sein, wenn Stilprobleme das Zusammenführen verhindern. Beginnen Sie mit "critical und high" und passen Sie es basierend auf der Erfahrung Ihres Teams an.
Umgang mit Bugbot-Meinungsverschiedenheiten
Manchmal markiert Bugbot etwas, das der Entwickler für ein falsch positives Ergebnis hält. Der empfohlene Workflow:
- Klicken Sie auf Resolve conversation beim Bugbot-Kommentar in GitHub
- Fügen Sie einen Kommentar hinzu, der erklärt, warum es ein falsch positives Ergebnis ist
- Wenn es ein wiederkehrendes falsch positives Ergebnis beim selben Muster ist, fügen Sie einen
// bugbot-ignore-Kommentar hinzu:
# bugbot-ignore: This is intentionally using eval for a DSL interpreter
result = eval(user_expression)
Fehlerbehebung "Disabled for This Repository"
Dies ist das am häufigsten gemeldete Bugbot-Problem. Befolgen Sie diesen Diagnose-Entscheidungsbaum.
Diagnoseschritt 1: GitHub-App-Installation prüfen
# Check if the Cursor app has access to your repo
gh api repos/{owner}/{repo}/installation --jq '.id'
Wenn dies eine 404 zurückgibt, ist die GitHub-App nicht für dieses Repository installiert.
Lösung: Gehen Sie zu GitHub > Settings > Integrations > Applications > Cursor > Configure und fügen Sie das Repository hinzu.
Diagnoseschritt 2: Repository-Einstellungen in Cursor prüfen
- Öffnen Sie die Cursor-Einstellungen
- Navigieren Sie zu Features > Bugbot
- Suchen Sie nach Ihrem Repository in der aktivierten Liste
- Wenn es nicht dort ist, klicken Sie auf Add Repository und wählen Sie es aus
Diagnoseschritt 3: Branch-Schutzregeln prüfen
Bugbot erfordert, dass Ihr Repository der GitHub-App erlaubt, Review-Kommentare zu posten. Wenn Ihre Branch-Schutzregeln zu restriktiv sind:
- Gehen Sie zu GitHub > Settings > Branches
- Bearbeiten Sie Ihre Branch-Schutzregel
- Stellen Sie sicher, dass Allow specified actors to bypass requirements die Cursor-App einschließt
- Stellen Sie sicher, dass die App nicht durch Restrict who can push to matching branches blockiert wird
Diagnoseschritt 4: Auf kollidierende Apps prüfen
Wenn Sie andere automatisierte Überprüfungstools installiert haben (CodeRabbit, GitHub Copilot, SonarQube), können diese mit Bugbot kollidieren.
Lösung: Deaktivieren Sie andere Review-Bots vorübergehend und prüfen Sie, ob Bugbot zu funktionieren beginnt. Wenn ja, müssen Sie die Tools so konfigurieren, dass sie koexistieren, was möglicherweise die Anpassung von Webhook-Einstellungen oder Review-Triggern erfordert.
Diagnoseschritt 5: Bugbot-Status prüfen
# Check Cursor service status
curl -s https://status.cursor.sh/api/v2/incidents.json | jq '.incidents[] | select(.status != "resolved")'
Wenn es einen aktiven Vorfall gibt, warten Sie, bis er behoben ist, und versuchen Sie es erneut.
Bugbot zeigt manchmal sofort nach einem Cursor-Update "disabled" an. Dies ist ein bekanntes Problem, bei dem das GitHub-Token neu authentifiziert werden muss. Gehen Sie zu Settings > Features > Bugbot, klicken Sie auf Disconnect und dann auf Reconnect Ihres GitHub-Kontos. Dadurch wird das Token aktualisiert, ohne Ihre Konfiguration zu verlieren.
Bugbot- und GitHub Teams-Integration: Tiefenanalyse
Teammitgliedschaft synchronisieren
Bugbot speichert die GitHub-Teammitgliedschaft für die Leistung zwischen. Wenn Sie ein Teammitglied hinzufügen oder entfernen, wird die Änderung möglicherweise nicht sofort widergespiegelt.
Um eine Synchronisierung zu erzwingen:
- Öffnen Sie die Cursor-Einstellungen
- Gehen Sie zu Features > Bugbot > Advanced
- Klicken Sie auf Sync GitHub Teams
- Warten Sie, bis die Synchronisierung abgeschlossen ist (normalerweise unter 30 Sekunden)
Mehrfach-Teammitgliedschaft
Wenn ein Entwickler zu mehreren Teams gehört, leitet Bugbot basierend auf der CODEOWNERS-Übereinstimmung weiter. Wenn eine Datei mehreren Teams gehört und der Entwickler in beiden ist, erhält er eine einzige Review-Anfrage, keine Duplikate.
Team-basierte Review-Richtlinien
Sie können unterschiedliche Review-Anforderungen pro Team konfigurieren:
{
"bugbot.teamPolicies": {
"security-team": {
"requiredReviews": 2,
"blockOnHighSeverity": true,
"additionalScanners": ["dependency-check"]
},
"frontend-team": {
"requiredReviews": 1,
"blockOnHighSeverity": false
}
}
}
Bugbot-Leistung und Grenzen
Überprüfungsgeschwindigkeit
Bugbot schließt eine Überprüfung normalerweise innerhalb von 30-90 Sekunden nach Öffnen oder Aktualisieren eines PR ab. Faktoren, die die Geschwindigkeit beeinflussen:
| Faktor | Auswirkung |
|---|---|
| PR-Größe (geänderte Zeilen) | Große Diffs dauern länger zu analysieren |
| Anzahl der Dateien | Jede Datei erfordert eine einzelne Analyse |
| Repository-Größe | Größere Codebases erfordern mehr Kontexterfassung |
| Aktuelle Auslastung | Spitzenzeiten können langsamere Antworten sehen |
Kommentarlimit
Standardmäßig postet Bugbot maximal 20 Kommentare pro Überprüfung. Dies verhindert, dass der PR-Autor überfordert wird. Sie können dies anpassen:
{
"bugbot.maxComments": 50
}
Wenn Bugbot bei jedem PR das Kommentarlimit erreicht, erwägen Sie, den Schweregrad-Schwellenwert zu erhöhen. Das Erreichen des Limits bedeutet, dass Bugbot viele Probleme mit niedriger Priorität findet. Diese herauszufiltern, macht die Überprüfung umsetzbarer.
Ratenlimits
Bugbot respektiert die GitHub-API-Ratenlimits. Wenn Ihre Organisation viele PRs gleichzeitig öffnet, können Reviews in die Warteschlange gestellt werden. Bugbot verarbeitet sie der Reihe nach, und alle Reviews werden schließlich abgeschlossen.
Best Practices für die Bugbot-Einführung
Im Lesemodus beginnen
Wenn Sie Bugbot zum ersten Mal in einem bestehenden Repository aktivieren, beginnen Sie im Lesemodus (keine Zusammenführungsblockierung). Dies lässt das Team sehen, was Bugbot findet, ohne den Workflow zu unterbrechen. Nach ein bis zwei Wochen der Überprüfung der Ergebnisse passen Sie die Konfiguration an und aktivieren die Zusammenführungsblockierung, falls angemessen.
Bugbot-Ergebnisse als Lernwerkzeuge verwenden
Bugbot-Ergebnisse gehen nicht nur um die Behebung des aktuellen PR. Sie sind Lernmöglichkeiten:
- Wiederkehrende Ergebnistypen verfolgen (z.B. "Null-Referenz-Risiko" erscheint bei 30% der PRs)
.cursor/rules-Einträge erstellen, um das Muster in zukünftigem Code zu verhindern- Interessante Ergebnisse in Team-Kanälen teilen
Regelmäßige Konfigurationsüberprüfung
Überprüfen Sie Ihre Bugbot-Konfiguration monatlich:
- Sind die Datei-Ausschlüsse noch angemessen?
- Sind die Schweregrad-Schwellenwerte richtig kalibriert? | Gibt es neue falsch positive Muster zu unterdrücken? | Ist das Kommentarlimit für Ihre aktuellen PR-Größen angemessen?
Zusammenfassung
Bugbot bringt automatisierte, intelligente Code-Überprüfung zu jedem Pull Request in Ihren mit Cursor verbundenen GitHub-Repositories. Das häufigste Problem, "disabled for this repository", wird fast immer durch die Überprüfung des GitHub-App-Installationsumfangs und die Sicherstellung, dass das Repository explizit hinzugefügt wurde, gelöst. Durch die Konfiguration von PR-Routing mit CODEOWNERS, das Justieren des Sicherheitsagenten und die Annahme eines inkrementellen Ansatzes für die Zusammenführungsblockierung kann Ihr Team Bugbot als zuverlässige erste Verteidigungslinie gegen Bugs und Sicherheitslücken nutzen.