Skip to main content

Problembehandlung bei Dependabot-Fehlern

Manchmal kann Dependabot keinen Pull Request auslösen, um deine Abhängigkeiten zu aktualisieren. Du kannst den Fehler überprüfen und die Blockierung von Dependabot aufheben.

Hinweis: Dein Websiteadministrator muss Dependabot updates für Ihre GitHub Enterprise Server-Instance einrichten, damit du dieses Feature verwenden kannst. Weitere Informationen findest du unter Aktivieren von Dependabot für dein Unternehmen.

Möglicherweise kannst du Dependabot updates nicht aktivieren oder deaktivieren, wenn eine Unternehmensbesitzerin eine Richtlinie auf Unternehmensebene festgelegt hat. Weitere Informationen findest du unter Erzwingen von Richtlinien für die Codesicherheit und -analyse für Unternehmen.

Informationen zu Dependabot-Fehlern

Dependabot löst Pull Requests zum Aktualisieren von Abhängigkeiten aus. Je nachdem, wie Dein Repository konfiguriert ist, kann Dependabot Pull Requests für Versionsupdates und/oder für Sicherheitsupdates auslösen. Du verwaltest diese Pull Requests auf dieselbe Weise wie alle anderen Pull Requests, aber es sind auch einige zusätzliche Befehle verfügbar. Weitere Informationen zum Aktivieren von Updates für Dependabot-Abhängigkeiten findest du unter Konfigurieren von Dependabot-Sicherheitsupdates und Konfigurieren von Versionsupdates von Dependabot.

Wenn etwas verhindert, dass Dependabot einen Pull Request auslöst, wird dies als Fehler gemeldet.

Note

Dependabot erstellt keine Pull Requests für inaktive Repositorys. Informationen zu den Inaktivitätskriterien findest du unter Informationen zu Dependabot-Sicherheitsupdates und Informationen zu Updates von Dependabot-Versionen (für Sicherheits- bzw. Versionsupdates).

Untersuchen von Fehlern bei Dependabot security updates

Wenn Dependabot daran gehindert wird, einen Pull Request zum Beheben einer Dependabot-Warnung zu erstellen, wird die Fehlermeldung in der Warnung angezeigt. Die Dependabot alerts-Ansicht zeigt eine Liste aller Warnungen an, die noch nicht behoben wurden. Für den Zugriff auf die Warnungsansicht klicke auf der Registerkarte Sicherheit für das Repository auf Dependabot alerts. Wenn ein Pull Request generiert wurde, der die anfällige Abhängigkeit korrigiert, enthält die Warnung einen Link zu diesem Pull Request.

Screenshot der Ansicht für Dependabot alerts, die zwei Warnungen anzeigt. Rechts neben einer Warnung wird ein Link zu einem Pull Request mit dem Titel „#353“ mit einer orangefarbenen Kontur hervorgehoben.

Es gibt mehrere Gründe, warum eine Warnung nicht über einen Pull Request-Link verfügt:

  1. Dependabot security updates sind nicht für das Repository aktiviert.
  2. Die Warnung ist für eine indirekte oder transitive Abhängigkeit vorgesehen, die in einer Sperrdatei nicht explizit definiert ist.
  3. Ein Fehler hat verhindert, dass Dependabot einen Pull Request erstellt.

Wenn ein Fehler verhindert hat, dass Dependabot einen Pull Request erstellt, kannst du Details des Fehlers anzeigen, indem du auf die Warnung klickst.

Untersuchen von Fehlern bei Dependabot version updates

Wenn Dependabot daran gehindert wird, einen Pull Request zum Aktualisieren einer Abhängigkeit in einem Ökosystem zu erstellen, zu erfahren, der das Fehlersymbol in der Manifestdatei veröffentlicht.

Die Manifestdateien, die von Dependabot verwaltet werden, werden auf der Registerkarte „Dependabot“ aufgelistet. Für den Zugriff auf diese Registerkarte klicke auf der Registerkarte Erkenntnisse für das Repository auf Abhängigkeitsdiagramm, und klicke dann auf die Registerkarte Dependabot.

Screenshot der Ansicht für Dependabot. Ein Warnungssymbol und ein Link mit dem Titel „Zuletzt überprüft vor 10 Stunden“ sind mit einer orangefarbenen Kontur hervorgehoben.

Wenn du die Protokolle für eine Manifestdatei anzeigen möchtest, klicke auf den Link Last checked TIME ago (Zuletzt überprüft vor ZEIT) und dann auf Protokolle anzeigen.

Grundlegendes zu Dependabot-Fehlern

Pull Requests für Sicherheitsupdates dienen zum Upgrade einer anfälligen Abhängigkeit auf die Mindestversion, die einen Fix für das Sicherheitsrisiko enthält. Im Gegensatz dazu dienen Pull Requests für Versionsupdates zum Upgrade einer Abhängigkeit auf die neueste Version, die nach dem Paketmanifest und den Dependabot-Konfigurationsdateien zulässig ist. Daher sind einige Fehler für einen Updatetyp spezifisch.

Dependabot kann DEPENDENCY nicht auf eine nicht anfällige Version aktualisieren

Nur Sicherheitsupdates. Dependabot kann keinen Pull Request erstellen, um die anfällige Abhängigkeit auf eine sichere Version zu aktualisieren, ohne andere Abhängigkeiten im Abhängigkeitsdiagramm für dieses Repository zu unterbrechen.

Jede Anwendung mit Abhängigkeiten hat ein Abhängigkeitsdiagramm, also einen gerichteten azyklischen Graph jeder Paketversion, von der die Anwendung direkt oder indirekt abhängt. Jedes Mal, wenn eine Abhängigkeit aktualisiert wird, muss dieses Diagramm aufgelöst werden, andernfalls wird die Anwendung nicht erstellt. Wenn ein Ökosystem über ein tiefes und komplexes Abhängigkeitsdiagramm verfügt, z. B. npm und RubyGems, ist es oft unmöglich, ein Upgrade für eine einzelne Abhängigkeit ohne ein Upgrade für das gesamte Ökosystem durchzuführen.

Die beste Möglichkeit, dieses Problem zu vermeiden, besteht darin, mit den zuletzt veröffentlichten Versionen auf dem neuesten Stand zu bleiben, z. B. durch Aktivieren von Versionsupdates. Dadurch wird die Wahrscheinlichkeit erhöht, dass ein Sicherheitsrisiko in einer Abhängigkeit durch ein einfaches Upgrade behoben werden kann, das das Abhängigkeitsdiagramm nicht unterbricht. Weitere Informationen findest du unter Konfigurieren von Versionsupdates von Dependabot.

Dependabot versucht, Abhängigkeiten ohne Warnung zu aktualisieren

Nur Sicherheitsupdates. Dependabot aktualisiert explizit definierte transitive Abhängigkeiten, die bei allen Ökosystemen anfällig sind. Bei npm löst Dependabot einen Pull Request aus, der auch die übergeordnete Abhängigkeit aktualisiert, wenn dies die einzige Möglichkeit ist, die transitive Abhängigkeit zu beheben.

Beispiel: Ein Projekt mit einer Abhängigkeit auf A Version ~2.0.0, die eine transitive Abhängigkeit auf B Version ~1.0.0 hat, wird in 1.0.1 aufgelöst.

my project
|
--> A (2.0.0) [~2.0.0]
       |
       --> B (1.0.1) [~1.0.0]

Wenn ein Sicherheitsrisiko für B Version <2.0.0 veröffentlicht wird und ein Patch unter 2.0.0 verfügbar ist, versucht Dependabot, B zu aktualisieren, was aber aufgrund der Einschränkung durch A nicht möglich ist, die nur niedrigere anfällige Versionen zulässt. Zum Beheben des Sicherheitsrisikos sucht Dependabot nach Updates für Abhängigkeit A, welche die Verwendung der reparierten Version B zulassen.

Dependabot generiert automatisch einen Pull Request, der sowohl die gesperrten übergeordneten als auch die untergeordneten transitiven Abhängigkeiten aktualisiert.

Dependabot kann eine offene Pullanforderung für ein Update, das bereits auf der Standardbranch angewendet wurde, nicht schließen

Dependabot schließt Pull Requests für Aktualisierungen von Abhängigkeiten, sobald es feststellt, dass diese Aktualisierungen in den Standardbranch übertragen wurden. In seltenen Fällen kann die Pullanforderung jedoch erneut geöffnet bleiben. Wenn Sie feststellen, dass Sie eine Aktualisierung manuell an eine Abhängigkeit vorgenommen haben und der Pull Request für dasselbe Update noch geöffnet ist, können Sie einen der folgenden Befehle in einem Kommentar für den Pull Request verwenden:

  • @dependabot recreate oder
  • @dependabot rebase.

Jeder Kommentar löst Dependabot aus, um zu überprüfen, ob die Abhängigkeit nicht mehr aktualisierbar oder anfällig ist. Wenn Dependabot feststellt, dass der Pull Request nicht mehr benötigt wird, schließt es der Pull Request in diesem speziellen Fall.

Weitere Informationen zu Dependabot Kommentarbefehlen finden Sie unter „Verwalten von Pull Requests für Abhängigkeitsupdates“.

Dependabot kann nicht auf die erforderliche Version aktualisiert werden, da bereits ein offener Pull Request für die neueste Version vorhanden ist.

Nur Sicherheitsupdates. Dependabot erstellt keinen Pull Request, um die anfällige Abhängigkeit auf eine sichere Version zu aktualisieren, da bereits ein offener Pull Request vorhanden ist, um diese Abhängigkeit zu aktualisieren. Dieser Fehler wird angezeigt, wenn ein Sicherheitsrisiko in einer einzigen Abhängigkeit erkannt wird und bereits ein offener Pull Request vorhanden ist, um die Abhängigkeit auf die neueste Version zu aktualisieren.

Du hast zwei Möglichkeiten: Du kannst den offenen Pull Request überprüfen und zusammenführen, sobald du sicher bist, dass die Änderung sicher ist. Alternativ kannst du diesen Pull Request schließen und einen neuen Pull Request für ein Sicherheitsupdate auslösen. Weitere Informationen findest du unter Manuelles Auslösen eines Dependabot-Pull Requests.

Es ist kein Sicherheitsupdate erforderlich, da ABHÄNGIGKEIT nicht mehr anfällig ist.

Nur Sicherheitsupdates. Dependabot können eine Pullanforderung nicht schließen, um eine Abhängigkeit zu aktualisieren, die nicht oder nicht mehr anfällig ist. Dieser Fehler wird möglicherweise angezeigt, wenn Abhängigkeitsdiagrammdaten veraltet sind oder wenn das Abhängigkeitsdiagramm und Dependabot nicht zustimmen, wenn eine bestimmte Version einer Abhängigkeit anfällig ist.

Um das Problem zu debuggen, sollten Sie zuerst die Abhängigkeitsdiagramm für Ihr Repository untersuchen und überprüfen, welche Version für die Abhängigkeit erkannt wurde und ob die identifizierte Version dem entspricht, was in Ihrem Repository verwendet wird.

Wenn Sie vermuten, dass Ihre Abhängigkeitsdiagrammdaten veraltet sind, müssen Sie möglicherweise das Abhängigkeitsdiagramm für Ihr Repository manuell aktualisieren oder Ihre Abhängigkeitsdaten weiter prüfen. Weitere Informationen findest du unter Fehler beim Abhängigkeitsdiagramm beheben.

Wenn Sie bestätigen können, dass die Abhängigkeitsversion nicht mehr anfällig ist, können Sie die Pullanforderung Dependabot schließen.

Dependabot-Timeout während des Updates

Dependabot brauchte länger als die zulässige maximale Zeit, um das erforderliche Update zu bewerten und einen Pull Request vorzubereiten. Dieser Fehler wird normalerweise nur für große Repositorys mit vielen Manifestdateien angezeigt, z. B. npm- oder yarn-Monorepo-Projekte mit Hunderten von package.json-Dateien. Die Bewertung von Aktualisierungen des Composer-Ökosystems dauert auch länger, und es kann zu einem Timeout kommen.

Dieser Fehler ist schwer zu beheben. Wenn es bei einem Versionsupdate zu einem Timeout kommt, kannst du die wichtigsten Abhängigkeiten angeben, die mit dem allow-Parameter aktualisiert werden sollen, oder alternativ den ignore-Parameter verwenden, um einige Abhängigkeiten von Updates auszuschließen. Durch das Aktualisieren deiner Konfiguration kann Dependabot das Versionsupdate überprüfen und den Pull Request in der verfügbaren Zeit generieren.

Wenn es bei einem Sicherheitsupdate zu einem Timeout kommt, kannst du die Wahrscheinlichkeit dafür verringern, indem du die Abhängigkeiten auf dem neuesten Stand hältst, z. B. durch Aktivieren von Versionsupdates. Weitere Informationen findest du unter Konfigurieren von Versionsupdates von Dependabot.

Dependabot kann keine weiteren Pull Requests öffnen

Es gibt ein Limit für die Anzahl der offenen Pull Requests, die von Dependabot generiert werden. Wenn dieses Limit erreicht ist, werden keine neuen Pull Requests geöffnet, und dieser Fehler wird gemeldet. Die beste Möglichkeit zum Beheben dieses Fehlers besteht darin, einige der offenen Pull Requests zu überprüfen und zusammenzuführen.

Es gibt separate Limits für Pull Requests für Sicherheits- und Versionsupdates, sodass offene Pull Requests für Versionsupdates nicht die Erstellung eines Pull Requests für ein Sicherheitsupdate blockieren können. Das Limit für Pull Requests für Sicherheitsupdates beträgt 10. Standardmäßig beträgt das Limit für Versionsupdates 5, aber du kannst diesen Wert mithilfe des open-pull-requests-limit-Parameters in der Konfigurationsdatei ändern. Weitere Informationen findest du unter Konfigurationsoptionen für die Datei dependabot.yml.

Die beste Möglichkeit zum Beheben dieses Fehlers besteht darin, einige der vorhandenen Pull Requests zusammenzuführen oder zu schließen und einen neuen Pull Request manuell auszulösen. Weitere Informationen findest du unter Manuelles Auslösen eines Dependabot-Pull Requests.

Dependabot kann deine Abhängigkeiten nicht auflösen oder darauf zugreifen.

Wenn Dependabot versucht zu überprüfen, ob Abhängigkeitsverweise in einem Repository aktualisiert werden müssen, jedoch nicht auf eine oder mehrere der verwiesenen Dateien zugreifen kann, schlägt der Vorgang mit der Fehlermeldung „Dependabot kann deine LANGUAGE-Abhängigkeitsdateien nicht auflösen“ fehl. Der API-Fehlertyp ist git_dependencies_not_reachable.

Wenn Dependabot nicht auf eine private Paketregistrierung zugreifen kann, in der sich eine Abhängigkeit befindet, wird einer der folgenden Fehler generiert:

  • „Dependabot can't reach a dependency in a private package registry“ (Dependabot kann eine Abhängigkeit in einer privaten Paketregistrierung nicht erreichen)
    (API-Fehlertyp: private_source_not_reachable)
  • „Dependabot can't authenticate to a private package registry“ (Dependabot kann sich nicht bei einer privaten Paketregistrierung authentifizieren)
    (API-Fehlertyp:private_source_authentication_failure)
  • „Dependabot timed out while waiting for a private package registry“ (Dependabot-Timeout beim Warten auf eine private Paketregistrierung)
    (API-Fehlertyp:private_source_timed_out)
  • „Dependabot couldn't validate the certificate for a private package registry“ (Dependabot konnte das Zertifikat für eine private Paketregistrierung nicht überprüfen)
    (API-Fehlertyp:private_source_certificate_failure)

Damit Dependabot die Abhängigkeitsverweise erfolgreich aktualisieren kann, stelle sicher, dass alle referenzierten Abhängigkeiten an zugänglichen Speicherorten gehostet werden.

Nur Versionsupdates. Bei der Durchführung von Sicherheits- oder Versionsupdates müssen einige Ökosysteme in der Lage sein, alle Abhängigkeiten von der jeweiligen Quelle aufzulösen, um zu überprüfen, ob die Updates erfolgreich waren. Wenn deine Manifest- oder Sperrdateien private Abhängigkeiten enthalten, muss Dependabot auf den Speicherort zugreifen können, an dem diese Abhängigkeiten gehostet werden. Organisationsbesitzer können Dependabot Zugriff auf private Repositorys gewähren, die Abhängigkeiten für ein Projekt innerhalb derselben Organisation enthalten. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation. Du kannst den Zugriff auf private Registrierungen in der Konfigurationsdatei dependabot.yml eines Repositorys konfigurieren. Weitere Informationen findest du unter Konfigurationsoptionen für die Datei dependabot.yml. Darüber hinaus bietet Dependabot keine Unterstützung für private GitHub-Abhängigkeiten für alle Paket-Manager. Weitere Informationen findest du unter Von Dependabot unterstützte Ökosysteme und Repositorys.

Dependabot kann einen Satz von Abhängigkeiten für Dependabot version updates

nicht in einem einzelnen Pull Request zusammenfassen

Du kannst nur Gruppen für Dependabot version updates erstellen. Dependabot security updates unterstützt keine gruppierten Aktualisierungen. Wenn ein gruppierter Pull Request für ein anfälliges Paket vorhanden ist, versucht Dependabot security updates immer, einen separaten Pull Request zu erstellen, auch wenn der vorhandene Gruppen-Pull Request ein Update für diesen oder für eine spätere Version ist.

Wenn Sie gruppierte Versionsupdates konfigurieren, müssen Sie Gruppen pro Paketökosystem konfigurieren. Um das Problem zu debuggen, empfehlen wir dir, die Protokolle anzusehen. Informationen zum Zugriff auf die Protokolle für ein Manifest findest du oben unter „Untersuchen von Fehlern bei Dependabot version updates“.

Möglicherweise hast du unbeabsichtigt leere Gruppen erstellt. Dies geschieht beispielsweise, wenn du dependency-type im allow-Schlüssel für den Gesamtauftrag festlegst.

allow:
  dependency-type: production
  # this restricts the entire job to production dependencies
  groups:
      development-dependencies:
        dependency-type: "development"
        # this group will always be empty

In diesem Beispiel führt Dependabot Folgendes aus:

  1. Sieh dir die Abhängigkeitsliste an und beschränke den Auftrag auf Abhängigkeiten, die nur in production verwendet werden.
  2. Versuche, eine Gruppe namens development-dependencies zu erstellen, die eine Teilmenge dieser reduzierten Liste ist.
  3. Vergewissere dich, dass die Gruppe development-dependencies leer ist, da alle development-Abhängigkeiten in Schritt 1 entfernt wurden.
  4. Aktualisiere alle Abhängigkeiten, die sich nicht in der Gruppe befinden, einzeln. Da die Gruppe für Abhängigkeiten in der Produktion leer ist, ignoriert Dependabot die Gruppe und erstellt einen separaten Pull Request für jede Abhängigkeit.

Du musst sicherstellen, dass die Konfigurationseinstellungen sich nicht gegenseitig aufheben, und sie in deiner Konfigurationsdatei entsprechend aktualisieren.

Weitere Informationen zum Konfigurieren von Gruppen für Dependabot version updates finden Sie unter Konfigurationsoptionen für die Datei dependabot.yml.

Dependabot kann eine der Abhängigkeiten in einem gruppierten Pull Request nicht aktualisieren

Nur Versionsupdates. Dependabot zeigt die fehlgeschlagene Aktualisierung in den Protokollen und in der Auftragszusammenfassung am Ende der Protokolle an. Verwende den Kommentar @dependabot recreate im Pull Request, um die Gruppe neu zu erstellen. Weitere Informationen findest du unter Verwalten von Pull Requests für Abhängigkeitsupdates.

Wenn die Abhängigkeit weiterhin nicht aktualisiert wird, solltest du die Konfiguration exclude-patterns verwenden, um die Abhängigkeit aus der Gruppe auszuschließen. Dependabot löst daraufhin einen separaten Pull Request aus, um die Abhängigkeit zu aktualisieren.

Wenn die Abhängigkeit immer noch nicht aktualisiert wird, liegt möglicherweise ein Problem mit der Abhängigkeit selbst oder mit Dependabot für dieses spezielle Ökosystem vor.

Wenn Sie Updates für die Abhängigkeit ignorieren möchten, müssen Sie eine der folgenden Aktionen ausführen.

CI-Fehler (Continuous Integration) bei gruppierten Pull Requests

Nur Versionsupdates. Wenn der Fehler auf eine einzelne Abhängigkeit zurückzuführen ist, solltest du die Konfiguration exclude-patterns verwenden, um die Abhängigkeit aus der Gruppe auszuschließen. Dependabot löst daraufhin einen separaten Pull Request aus, um die Abhängigkeit zu aktualisieren.

Wenn Sie Updates für die Abhängigkeit ignorieren möchten, müssen Sie eine der folgenden Aktionen ausführen.

Wenn weiterhin CI-Fehler auftreten, solltest du die Gruppenkonfiguration entfernen, damit Dependabot wieder einzelne Pull Requests für die Abhängigkeiten erstellt. Dann solltest du überprüfen und bestätigen, dass die Aktualisierung für jeden einzelnen Pull Request ordnungsgemäß funktioniert.

Manuelles Auslösen eines Dependabot-Pull Requests

Wenn du die Blockierung von Dependabot aufhebst, kannst du einen neuen Versuch zum Erstellen eines Pull Requests manuell auslösen.

  • Sicherheitsupdates: Zeige die Dependabot-Warnung an, die den Fehler anzeigt, den du behoben hast, und klicke auf Dependabot-Sicherheitsupdate erstellen.
  • Versionsupdates: Klicke auf der Registerkarte Erkenntnisse für das Repository auf Abhängigkeitsdiagramm, und klicke dann auf die Registerkarte Dependabot. Klicke auf Last checked TIME ago (Zuletzt überprüft vor ZEIT), um die Protokolldatei anzuzeigen, die Dependabot während der letzten Überprüfung auf Versionsupdates generiert hat. Klicke auf Nach Updates suchen.

Weitere Informationsquellen