Fehlerbehebung in Workflows

Sie können die Tools GitHub Actions verwenden, um Ihre Workflows zu debuggen.

In diesem Artikel

Vorschläge zur anfänglichen Problembehandlung

Es gibt mehrere Möglichkeiten, Fehler bei der Ausführung von Workflows zu beheben.

Hinweis

Wenn Sie sich in einem GitHub Copilot Kostenlos Abonnement befinden, zählt dies zu Ihrem Monatlichen Chatnachrichtenlimit.

Verwenden von GitHub Copilot

Um einen Chat mit GitHub Copilot zu einer fehlgeschlagenen Workflow-Ausführung zu öffnen, haben Sie zwei Möglichkeiten:

  • Klicken Sie neben der fehlgeschlagenen Überprüfung im Merge-Feld auf und dann auf Fehler erklären.
  • Klicke im Zusammenführungsfeld auf die fehlgeschlagene Überprüfung. Klicken Sie oben auf der Zusammenfassungsseite der Workflowausführung auf "Fehler erklären".

Dies öffnet ein Chatfenster mit GitHub Copilot, in dem Anweisungen zur Behebung des Problems gegeben werden.

Verwenden von Workflowausführungsprotokollen

Jede Workflowausführung generiert Aktivitätsprotokolle, die du anzeigen, durchsuchen und herunterladen kannst. Weitere Informationen finden Sie unter Verwenden von Workflowausführungsprotokollen.

Aktivieren der Debugprotokollierung

Wenn die Workflow-Logs nicht genügend Details zur Diagnose enthalten, warum ein Workflow, ein Job oder ein Schritt nicht wie erwartet abläuft, kannst du die zusätzliche Debug-Protokollierung aktivieren. Weitere Informationen finden Sie unter Aktivieren der Debugprotokollierung.

Wenn dein Workflow bestimmte Tools oder Aktionen verwendet, kann das Aktivieren der Debug- oder ausführlichen Protokollierungsoptionen dazu beitragen, detailliertere Ausgaben für die Problembehandlung zu generieren. Du kannst z. B. npm install --verbose für npm oder GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ... für Git verwenden.

Überprüfen von Abrechnungsfehlern

Die Verwendung von Aktionen umfasst Runnerminuten und Speicher für Workflowartefakte. Weitere Informationen finden Sie unter Abrechnung für GitHub Actions.

Festlegen eines Budgets

Das Festlegen eines Aktionsbudgets kann dazu beitragen, die Blockierung von Workflows aufgrund von Abrechnungs- oder Speicherfehlern sofort aufzuheben. Es ermöglicht, weitere Minuten und die Speichernutzung bis zum festgelegten Budgetbetrag in Rechnung zu stellen. Weitere Informationen findest du unter Einrichten von Budgets zum Kontrollieren der Ausgaben für Produkte mit verbrauchseinheitenbasierter Abrechnung.

Überprüfung der GitHub Actions Aktivität anhand von Metriken

Informationen zur Analyse der Effizienz und Zuverlässigkeit deiner Workflows mithilfe von Metriken findest du unter Anzeigen von GitHub Actions-Metriken.

Problembehandlung bei Workflowtriggern

Du kannst das Feld on: deines Workflows überprüfen, um zu verstehen, was erwartungsgemäß den Workflow auslösen wird. Weitere Informationen finden Sie unter Auslösen eines Workflows.

Eine vollständige Liste der verfügbaren Ereignisse findest du unter Ereignisse zum Auslösen von Workflows.

Bedingungen zum Auslösen von Ereignissen

Einige auslösende Ereignisse werden nur vom Standardbranch ausgeführt (d. h. issues, schedule). Workflowdateiversionen, die außerhalb des Standardbranch vorhanden sind, werden bei diesen Ereignissen nicht ausgelöst.

Workflows werden nicht für pull_request-Aktivitäten ausgeführt, wenn der Pull Request einen Mergekonflikt aufweist.

Workflows, die andernfalls bei der push- oder pull_request-Aktivität ausgelöst werden, werden übersprungen, wenn die Commitnachricht eine Anmerkung zum Überspringen enthält. Weitere Informationen finden Sie unter Überspringen von Workflowausführungen.

Geplante Workflows, die zu unerwarteten Zeiten ausgeführt werden

Geplante Ereignisse können in Zeiträumen mit hoher Auslastung von GitHub Actions Workflowausführungen verzögert werden.

Eine hohe Last ist unter anderem zu Beginn jeder Stunde zu verzeichnen. Wenn die Auslastung ausreichend hoch ist, werden einige Aufträge in der Warteschlange möglicherweise gelöscht. Um die Wahrscheinlichkeit einer Verzögerung zu verringern, kannst du deinen Workflow so planen, dass er zu einer anderen Uhrzeit ausgeführt wird. Weitere Informationen finden Sie unter Ereignisse zum Auslösen von Workflows.

Filtern und Diff-Grenzwerte

Bestimmte Ereignisse ermöglichen das Filtern nach Branch, Tag und/oder Pfaden, die du anpassen kannst. Die Workflowausführungserstellung wird übersprungen, wenn die Filterbedingungen gelten, um den Workflow herauszufiltern.

Du kannst Sonderzeichen mit Filtern verwenden. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Bei der Pfadfilterung ist die Auswertung von Diffs auf die ersten 300 Dateien beschränkt. Wenn Dateien geändert werden, die nicht mit den ersten 300 vom Filter zurückgegebenen Dateien übereinstimmen, wird der Workflow nicht ausgeführt. Weitere Informationen finden Sie unter Workflowsyntax für GitHub Actions.

Fehlerbehebung bei der Workflowausführung

Die Workflowausführung umfasst alle Probleme, die nach dem Auslösen des Workflows auftreten und wenn eine Workflowausführung erstellt wurde.

Debuggen von Auftragsbedingungen

Wenn ein Auftrag unerwartet übersprungen wurde oder ausgeführt wurde, obwohl du erwartetest, dass er übersprungen würde, kannst du die Ausdrucksauswertung anzeigen, um zu verstehen, warum:

  1. Klicken Sie auf den Job in der Workflow-Ausführung.
  2. Laden Sie das Protokollarchiv aus dem Menü des Auftrags herunter.
  3. Öffnen Sie die Datei JOB-NAME/system.txt .
  4. Suchen Sie nach den Evaluating, Expanded und Result Zeilen.

In der Expanded Zeile werden die tatsächlichen Laufzeitwerte angezeigt, die in Ihre if Bedingung eingesetzt wurden, wodurch deutlich wird, warum der Ausdruck zu true oder false ausgewertet wurde.

Weitere Informationen finden Sie unter Anzeigen von Protokollen zu Auftragsbedingungsausdrücken.

Abbrechen von Workflows

Wenn der Standardabbruch über die UI oder API nicht wie erwartet verarbeitet wird, kann eine bedingte Anweisung für ihre ausgeführten Workflowaufträge konfiguriert sein, die dazu führen, dass sie nicht abgebrochen werden.

In diesen Fällen kannst du die API nutzen, um die Ausführung abzubrechen. Weitere Informationen finden Sie unter REST-API-Endpunkte für Workflowausführungen.

Eine häufige Ursache kann die Verwendung der always()Statusprüfungsfunktion sein, die true zurückgibt, auch beim Abbruch. Eine Alternative besteht darin, die Umkehrung der cancelled()-Funktion ${{ !cancelled() }} zu verwenden.

Weitere Informationen findest du unter Steuern der Auftragsausführung mithilfe von Bedingungen und Einen Workflow-Lauf abbrechen.

Problembehandlung bei Runnern

Definieren von Runnerbezeichnungen

GitHub-gehostete Runner verwenden vordefinierte Labels, die im actions/runner-images-Repository gepflegt werden.

Es wird empfohlen die Verwendung eindeutiger Bezeichnungsnamen für größere und selbstgehostete Runner. Wenn eine Bezeichnung mit einer der vorhandenen voreingestellten Bezeichnungen übereinstimmt, können Runnerzuweisungsprobleme auftreten, bei denen keine Garantie besteht, auf welcher übereinstimmenden Runneroption der Auftrag ausgeführt wird.

Selbstgehosteten Runnern

Wenn du selbstgehostete Runner verwendest, kannst du ihre Aktivitäten einsehen und häufige Probleme diagnostizieren.

Weitere Informationen finden Sie unter Überwachen und Beheben von Problemen mit selbstgehosteten Runnern.

Runner-IP-Adressen, die von Sicherheitsscannern gekennzeichnet sind

GitHub-gehostete Runner verwenden dynamisch zugewiesene IP-Adressen aus gemeinsamer Infrastruktur. Diese IP-Adressen werden über die Meta-API veröffentlicht (z. B. die Schlüssel actions und actions_macos). Weitere Informationen findest du unter REST-API-Endpunkte für Metadaten.

Drittanbieter für Threat Intelligence-Dienste, IP-Zuverlässigkeitsscanner oder Firewallanbieter kennzeichnen diese IP-Adressen möglicherweise als "böswillig" oder "verdächtig". Da die zugrunde liegende Infrastruktur gemeinsam genutzt wird, kann die Aktivität anderer Benutzer derselben Infrastruktur die Zuverlässigkeitsbewertungen beeinflussen, die diesen Adressen zugewiesen sind.

GitHub steuert keine IP-Zuverlässigkeitslisten von Drittanbietern und kann ihre Genauigkeit oder Aktualisierungshäufigkeit nicht kommentieren. Um festzustellen, ob eine IP-Adresse zu den von GitHub gehosteten Runnern gehört, überprüfen Sie die IP-Bereiche, die von der Meta-API zurückgegeben werden.

Wenn Sie eine Sicherheitsbedenken bezüglich einer Microsoft IP-Adresse haben, melden Sie sie an die Microsoft Security Response Center (MSRC).

Vorschläge zur Netzwerkproblembehandlung

Unser Support ist für Netzwerkprobleme eingeschränkt, die Folgendes umfassen:

  • Deine Netzwerke
  • Externe Netzwerke
  • Systeme von Drittanbietern
  • Allgemeine Internetkonnektivität

Um den Echtzeitplattformstatus von GitHub anzuzeigen, siehe GitHub Status.

Überprüfe bei anderen netzwerkbezogenen Problemen die Netzwerkeinstellungen deiner Organisation und den Status aller Drittanbieterdienste, auf die du zugreifst. Wenn die Probleme weiterhin bestehen, wende dich an deine Netzwerkadministratoren, um weitere Unterstützung zu erhalten.

Wenn Sie sich nicht über das Problem sicher sind, wenden Sie sich an GitHub-Support. Ausführliche Informationen zum Kontaktieren des Supports findest du unter GitHub-Support kontaktieren.

DNS

Probleme können aufgrund der Konfiguration des Domain Name Systems (DNS), seiner Auflösung oder Resolver-Problemen auftreten. Es wird empfohlen, die verfügbaren Protokolle und die Herstellerdokumentation zu lesen oder sich an deine Administratoren zu wenden, um weitere Unterstützung zu erhalten.

Firewalls

Aktivitäten werden möglicherweise durch Firewalls blockiert. In diesem Fall solltest du die verfügbaren Protokolle sowie die Dokumentation des Anbieters ansehen oder dich an deine Administratoren wenden, um weitere Unterstützung zu erhalten.

Proxys

Aktivitäten können fehlschlagen, wenn ein Proxy für die Kommunikation verwendet wird. Es ist gute Praxis, verfügbare Protokolle zu überprüfen, die Dokumentation des Anbieters zu lesen oder sich mit deinen Administratoren zu beraten, um zusätzliche Unterstützung zu erhalten.

Informationen zum Konfigurieren der Runneranwendung für die Verwendung eines Proxys findest du unter Verwendung von Proxyservern mit einem Runner.

Subnetze

Es können Probleme mit Subnetzen auftreten, die verwendet werden oder sich mit einem vorhandenen Netzwerk überschneiden, z. B. innerhalb von virtuellen Cloudanbietern oder Docker-Netzwerken. In solchen Fällen empfiehlt es sich, die verwendete Netzwerktopologie und die verwendeten Subnetze zu überprüfen.

Zertifikate

Probleme können durch selbstsignierte oder benutzerdefinierte Zertifikatketten und Zertifikatspeicher auftreten. Du kannst überprüfen, ob ein verwendetes Zertifikat nicht abgelaufen ist und derzeit vertrauenswürdig ist. Zertifikate können mit curl oder ähnlichen Tools überprüft werden. Du kannst auch die verfügbaren Protokolle und die Dokumentation des Anbieters überprüfen oder sich an deine Administratoren wenden, um weitere Unterstützung zu erhalten.

IP-Listen

IP-Zulassungs- oder Verweigerungslisten können die erwartete Kommunikation unterbrechen. Wenn ein Problem vorliegt, solltest du die verfügbaren Protokolle und die Herstellerdokumentation lesen oder dich an deine Administratoren wenden, um weitere Unterstützung zu erhalten.

Informationen zu den IP-Adressen von GitHub, wie sie von GitHub-gehosteten Runnern verwendet werden, finden Sie unter Informationen zu den IP-Adressen von GitHub.

Statische IP-Adressen sind zur Verwendung mit von GitHub gehosteten größeren Runnern verfügbar. Weitere Informationen findest du unter Verwalten größerer Runner.

Betriebssysteme und Softwareanwendungen

Zusätzlich zu Firewalls oder Proxys können Anpassungen an von GitHub gehosteten Runnern, etwa die Installation zusätzlicher Softwarepakete, zu Störungen der Kommunikation führen. Informationen zu den verfügbaren Anpassungsoptionen findest du unter Anpassen von GitHub-gehosteten Runnern.

Azure privates Netzwerk für GitHub-gehostete Runner

Probleme können durch die Verwendung von auf GitHub gehosteten Runnern in den Einstellungen Ihrer konfigurierten Azure Virtual Networks (VNETs) entstehen.

Hinweise zur Problembehandlung finden Sie unter AUTOTITLE oderProblembehandlung von Azure-Privatnetzwerkkonfigurationen für GitHub-gehostete Runner in Ihrer Organisation in den GitHub Enterprise Cloud Dokumenten.