Zum Hauptinhalt springen
Die Automatisierung CI Failure Fixer hält Ihre Pull Requests ohne menschliches Eingreifen im grünen Bereich. Jedes Mal, wenn ein CI-Check bei einer PR fehlschlägt, die nicht von Devin erstellt wurde, öffnet Devin den fehlgeschlagenen Job, liest die Build- und Test-Logs, ermittelt die Ursache und pusht einen Fix in denselben Branch — anschließend führt Devin die Suite erneut aus, um zu prüfen, ob der Check erfolgreich durchläuft.

Diese Vorlage verwenden

Öffnen Sie CI Failure Fixer in Devin und erstellen Sie die Automatisierung mit der Standardkonfiguration. Sie können sie vor dem Speichern anpassen.
Sie möchten eine praktische Schritt-für-Schritt-Anleitung? Im Schritt-für-Schritt-Tutorial für CI Failure Fixer finden Sie eine vollständige Anleitung.

Was diese Automatisierung macht

Diese Vorlage verknüpft den GitHub-Webhook check_run mit einer Devin-Sitzung. Devin hat den vollständigen Kontext des Pull Requests (PR) und die URL des fehlgeschlagenen Jobs, sodass es den Branch herunterladen, den Fehler lokal reproduzieren und schrittweise an einer Behebung arbeiten kann, ohne dass Sie dafür jemals Ihren Laptop öffnen müssen. Die Automatisierung enthält außerdem einen integrierten Schutzmechanismus, der alle Commits von devin-ai-integration[bot] überspringt, damit Sie nicht in eine Schleife geraten, in der Devin seine eigene Arbeit korrigiert.

So funktioniert es

Auslöser: GitHub-Ereignischeck.run
  • Ereignis: github:check_run
    • Bedingungen:
      • action eq completed
      • check_run.conclusion eq failure
      • repository.full_name eq your-org/your-repo
Was Devin macht: Startet eine Sitzung mit dem vollständigen Kontext des Ereignisses, führt den untenstehenden Prompt aus und benachrichtigt Sie optional bei einem Fehler.

Voraussetzungen

Beispiel-Prompt

Die Vorlage enthält diesen Prompt standardmäßig. Sie können ihn nach einem Klick auf Vorlage verwenden bearbeiten oder unverändert lassen.

Einrichtung

  1. Öffnen Sie Automations → Templates in Devin.
  2. Klicken Sie auf CI Failure Fixer. Die Erstellungsseite wird mit dieser Vorlage bereits ausgefüllt geöffnet.
  3. Verbinden Sie alle erforderlichen Integrationen und installieren Sie MCP-Server, falls Sie das noch nicht getan haben.
  4. Ersetzen Sie alle Platzhalterwerte in den Trigger-Bedingungen (zum Beispiel your-org/your-repo durch Ihr tatsächliches Repo).
  5. Prüfen Sie den Prompt und passen Sie ihn an die Sprache, Konventionen und Guardrails Ihres Teams an.
  6. Klicken Sie auf Create automation.
Die meisten Automatisierungsvorlagen enthalten empfohlene ACU- und Aufruflimits, um die Kosten in der frühen Rollout-Phase zu begrenzen. Belassen Sie sie zunächst unverändert, bis Sie sicher sind, wie sich die Automatisierung verhält, und erhöhen Sie sie dann entsprechend Ihrer Arbeitslast.

Wann Sie diese Vorlage verwenden sollten

  • Instabile Tests, die Merges über Nacht oder außerhalb der Arbeitszeiten blockieren
  • Lint-, Type-Check- und Formatierungsfehler, die Sie lieber nicht von Hand beheben möchten
  • Fehlende Imports, veraltete Snapshots und triviale Testfehler bei PRs aus der Community
  • Blockaden für Entwickler beseitigen, ohne dafür einen weiteren Entwickler aus fokussierter Arbeit herauszureißen

Ideen zur Anpassung

  • Begrenzen Sie den Trigger auf ein einzelnes Repo oder erweitern Sie ihn auf jedes Repo in einer Org
  • Fügen Sie eine Bedingung hinzu, die nur bei bestimmten Check-Namen ausgelöst wird (z. B. nur lint, nicht die gesamte Matrix)
  • Erhöhen Sie die ACU-Obergrenze, wenn Ihre Testsuite lange läuft, oder senken Sie sie, um die Kosten zu begrenzen
  • Kombinieren Sie dies bei Fehlschlägen mit einer Slack-Benachrichtigung, damit ein menschlicher Reviewer einspringen kann, wenn Devin aufgibt

Siehe auch