Zum Hauptinhalt springen

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

Bugbot

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
tipp

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:

  1. Cursor Pro oder Business-Plan - Bugbot ist in der kostenlosen Version nicht verfügbar
  2. Ein GitHub-Repository mit aktivierten Pull-Request-Workflows
  3. Admin- oder Maintainer-Zugriff auf das Repository (für die App-Installation erforderlich)
  4. 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:

  1. Öffnen Sie Cursor und navigieren Sie zu Settings > Features > Bugbot
  2. Klicken Sie auf Connect GitHub Account
  3. Sie werden zu GitHub weitergeleitet, um die Cursor-App zu autorisieren
  4. 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
warnung

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:

  1. Öffnen Sie Cursor Settings (Cmd/Ctrl + ,)
  2. Navigieren Sie zu Features > Bugbot
  3. Schalten Sie Enable Bugbot auf ON
  4. 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:

  1. CODEOWNERS-Datei - Falls vorhanden, werden die Eigentümer der geänderten Dateien zu Reviewern
  2. GitHub Teams-Mapping - Team-basiertes Routing über Bugbot-Konfiguration
  3. 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:

  1. Stellen Sie sicher, dass Ihre GitHub-Organisation Teams unter Org Settings > Teams eingerichtet hat
  2. Fügen Sie Mitglieder zu jedem Team hinzu
  3. Referenzieren Sie Teamnamen (mit @-Präfix) in CODEOWNERS
  4. Gehen Sie in Cursor zu Settings > Features > Bugbot > Advanced
  5. Aktivieren Sie Use GitHub Teams for routing
tipp

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
}
StrengVerhalten
strictMeldet alle Ergebnisse, einschließlich kleinerer Stilprobleme
balancedMeldet Bugs, Sicherheitsprobleme und signifikante Stilprobleme (Standard)
lenientMeldet 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__/**"
]
}
}
warnung

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:

  1. Gehen Sie zu Settings > Branches > Branch protection rules
  2. Bearbeiten Sie die Regel für Ihren Hauptbranch
  3. 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:

  1. Settings > Features > Bugbot > Workflow
  2. Aktivieren Sie Block merge on critical findings
  3. Legen Sie den Schweregrad-Schwellenwert für die Blockierung fest (Standard: critical und high)
tipp

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:

  1. Klicken Sie auf Resolve conversation beim Bugbot-Kommentar in GitHub
  2. Fügen Sie einen Kommentar hinzu, der erklärt, warum es ein falsch positives Ergebnis ist
  3. 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​

  1. Öffnen Sie die Cursor-Einstellungen
  2. Navigieren Sie zu Features > Bugbot
  3. Suchen Sie nach Ihrem Repository in der aktivierten Liste
  4. 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:

  1. Gehen Sie zu GitHub > Settings > Branches
  2. Bearbeiten Sie Ihre Branch-Schutzregel
  3. Stellen Sie sicher, dass Allow specified actors to bypass requirements die Cursor-App einschließt
  4. 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.

warnung

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:

  1. Öffnen Sie die Cursor-Einstellungen
  2. Gehen Sie zu Features > Bugbot > Advanced
  3. Klicken Sie auf Sync GitHub Teams
  4. 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:

FaktorAuswirkung
PR-Größe (geänderte Zeilen)Große Diffs dauern länger zu analysieren
Anzahl der DateienJede Datei erfordert eine einzelne Analyse
Repository-GrößeGrößere Codebases erfordern mehr Kontexterfassung
Aktuelle AuslastungSpitzenzeiten 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
}
tipp

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:

  1. Wiederkehrende Ergebnistypen verfolgen (z.B. "Null-Referenz-Risiko" erscheint bei 30% der PRs)
  2. .cursor/rules-Einträge erstellen, um das Muster in zukünftigem Code zu verhindern
  3. 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.