Skip to main content

Einrichtung der automatischen Codeabdeckung

Ein KI-basierter Agent kann Ihr Repository analysieren und einen funktionierenden Codeabdeckungsworkflow generieren, sodass Sie mit der Überwachung der Testabdeckung beginnen können, ohne die CI-Konfiguration manuell zu erstellen.

Wer kann dieses Feature verwenden?

GitHub Team oder GitHub Enterprise Cloud

Wenn Sie die automatische Einrichtung für die Codeabdeckung verwenden, analysiert ein KI-basierter Agent Ihr Repository, identifiziert Ihr Testframework und öffnet eine Pull-Anforderung mit einem Abdeckungsworkflow, der zur Überprüfung bereit ist.

Es gibt keine zusätzlichen Kosten für die Verwendung dieses Features.

Funktionsweise des Agents

Der Agent arbeitet in drei Phasen:

  1. Ermittlung: Der Agent liest Ihre CI-Konfiguration, Dokumentation und Builddateien, um Ihre Projektstruktur zu verstehen und Ihr Testframework zu identifizieren.
  2. Ausführung: Der Agent installiert Abhängigkeiten, erstellt das Projekt und führt Ihre Tests mit aktivierter Abdeckung aus. Wenn die Abdeckungstools noch nicht konfiguriert sind, fügt der Agent sie zu Ihrer Projektkonfiguration hinzu (z vitest.config.ts . B. oder jest.config.js).
  3. Workflowintegration: Wenn der Agent einen gültigen Abdeckungsbericht erstellt, überprüft er, ob Ihr Repository bereits über einen GitHub Actions Workflow verfügt, der Tests für Pullanforderungen ausführt. Wenn ja, erweitert der Agent diesen Workflow mit einem Uploadschritt für die Abdeckung. Andernfalls wird eine neue Workflowdatei erstellt und eine Pullanforderung geöffnet.

Wenn der Agent beendet wird

Der Agent kann vor dem Öffnen einer Pullanforderung in den folgenden Situationen beendet werden:

  • Es wurden keine Tests gefunden. Der Agent konnte keine Tests für Instrumentieren finden, daher gibt es nichts, für das eine Abdeckung generiert werden muss.
  • Der Build kann nicht reproduzieren. Fehlende private Registrierungen, proprietäre SDKs oder Systemabhängigkeiten verhindern, dass der Agent die Testsuite überprüft.

Wenn der Agent unerwartete Ergebnisse stoppt oder erzeugt, können Sie das Sitzungsprotokoll des Agents auf Details überprüfen. Navigieren Sie in Ihrem Repository zur Registerkarte "Aufgaben ", um die sitzung zu finden, die dem Versuch der Workflowgenerierung zugeordnet ist.

  • Nicht unterstützte Berichtskonvertierung. Der Agent rekonstruiert cobertura XML nicht aus Berichten, die nur aggregierte Indikatoren verfügbar machen. Beispielsweise enthält JaCoCo XML nicht genügend Linien- und Verzweigungsstruktur für einen vertrauenswürdigen Cobertura-Upload, sodass JVM-Projekte, die nur JaCoCo XML produzieren, stattdessen manuelle Einrichtung benötigen.

Ergebnisse der Pull-Anforderung

Hinweis

Der Agent öffnet die Pull-Anforderung sofort mit einem anfänglichen Planungs-Commit, der keine Codeänderungen enthält. Der tatsächliche Implementierungs-Commit kommt in der Regel ein paar Minuten später an. Wenn die Pullanforderung anfänglich 0 geänderte Dateien anzeigt, warten Sie einige Minuten, und aktualisieren Sie die Seite.

Wenn der Agent erfolgreich eine Pullanforderung öffnet, befindet sich die Pullanforderung möglicherweise in einem der folgenden Zustände:

  • Zusammenführungsfähige as-is: Der Workflow wird erfolgreich in CI abgeschlossen und der Abdeckungsupload ordnungsgemäß ausgeführt.
  • Bereit zum Durchlaufen: Der Workflow wird ausgeführt, erfordert jedoch Anpassungen (z. B. fehlende geheime Schlüssel, selbst gehostete Läuferkonfiguration oder Pfadunterschiede zwischen lokaler Überprüfung und CI).
  • Nützlich als Referenz: Betreuer bevorzugen es, die Abdeckung selbst zu konfigurieren, wobei die Pullanforderung des Agents als Ausgangspunkt für die ermittelten Build- und Testbefehle verwendet wird.

Weiterführende Lektüre