Automatische Abhängigkeitsübermittlung

Konfigurieren des Netzwerkzugriffs für selbst gehostete Läufer

Wenn Ihre selbst gehosteten Runner hinter einer Firewall mit eingeschränktem ausgehendem Internetzugriff arbeiten, müssen Sie bestimmte URLs zur Erlaubnisliste für die automatische Übermittlung von Abhängigkeiten hinzufügen. Die erforderlichen URLs hängen von den Ökosystemen ab, die Ihre Repositorys verwenden.

Erforderliche URLs für alle Ökosysteme

Diese URLs sind für alle Workflows für die automatische Abhängigkeitsübermittlung erforderlich:

•         `https://github.com`— Erforderlich für den Zugriff auf GitHub und Herunterladen von Aktionen.
  

•         `https://api.github.com`—Erforderlich für GitHub API-Zugriff.
  

•         `https://*.githubusercontent.com`— Erforderlich für das Herunterladen von Aktionsquellcode und -versionen (einschließlich `raw.githubusercontent.com`, `github-releases.githubusercontent.com`und `objects.githubusercontent.com`).
  

Ökosystemspezifische URLs

Je nach den von Ihnen verwendeten Ökosystemen müssen Sie möglicherweise zusätzliche URLs zulassen.

Los geht's

•         `https://go.dev`– Zum Herunterladen der Go-Toolkette.
  

•         `https://golang.org`– Alternative Domäne für Downloads für "Go".
  

•         `https://proxy.golang.org`– Offizieller Go-Modulproxy zum Herunterladen von Go-Modulen während der Abhängigkeitserkennung.
  

Java (Maven und Gradle)

•         `https://repo.maven.apache.org`— Maven Central Repository zum Herunterladen von Abhängigkeiten.
  

•         `https://api.adoptium.net`— Zum Herunterladen von Adoptium/Temurin JDK-Verteilungen (Standardverteilung verwendet von `actions/setup-java`).
  

Wenn Sie eine andere JDK-Verteilung verwenden, benötigen Sie möglicherweise auch Folgendes:

•         `https://aka.ms` und `https://download.microsoft.com` – Für Microsoft Build of OpenJDK (Hinweis: `aka.ms` wird auch für .NET Downloads verwendet).
  

•         `https://download.oracle.com`— für Oracle JDK.
  

•         `https://api.azul.com`—Für Azul Zulu OpenJDK.
  

.NET (C#, F#, Visual Basic)

•         `https://aka.ms` – Microsoft URL-Verkürzungsdienst, der zu .NET Download-Standorte umleitet.
  

•         `https://builds.dotnet.microsoft.com` – Primärer Feed für .NET SDK- und Laufzeitdownloads.
  

•         `https://ci.dot.net` – Sekundärer Feed für .NET-Builds.
  

Python

•         `https://python.org` – Zum Herunterladen von Python-Interpretern.
  

Verwenden sie GitHub-hosted größere Runner für die automatische Abhängigkeitseinreichung

GitHub Team- oder GitHub Enterprise Cloud-Benutzer können größere Runner verwenden, um automatische Abhängigkeitseinreichungsaufträge auszuführen.

1. Stellen Sie einen größeren Runner auf Organisationsebene mit dem Namen dependency-submission bereit. Weitere Informationen findest du unter Hinzufügen eines größerer Runner zu einer Organisation.
2. Gewähren Sie Ihrem Repository Zugriff auf den Runner. Weitere Informationen findest du unter Gewähren des Zugriffs auf größere Runner für Repositorys.
3. Klicken Sie unter „Abhängigkeitsdiagramm“ auf das Dropdownmenü neben „Automatische Abhängigkeitseinreichung“ und wählen Sie dann Für markierte Runners aktiviert aus.

Problembehebung bei der automatischen Übermittlung von Abhängigkeiten

Die automatische Abhängigkeitsübermittlung speichert Paketdownloads zwischen Ausführungen mithilfe der Cache-Aktion bestmöglich zwischen, um Workflows zu beschleunigen. Für selbstgehostete Runner solltest du diesen Cache in deiner eigenen Infrastruktur verwalten. Dazu kannst du die integrierte Zwischenspeicherung deaktivieren, indem du die Umgebungsvariable GH_DEPENDENCY_SUBMISSION_SKIP_CACHE auf true festlegst. Weitere Informationen finden Sie unter Speichern von Informationen in Variablen.

Manifestdeduplizierung

Ein Repository kann mehrere Methoden für die Abhängigkeitsübermittlung verwenden, was dazu führen kann, dass dasselbe Paketmanifest mehrmals gescannt wird, wodurch unterschiedliche Ausgaben bei jedem Scan möglich sind. Das Abhängigkeitsdiagramm verwendet Deduplizierungslogik, um die Ausgaben zu analysieren und die genauesten Informationen für jede Manifestdatei zu priorisieren.

Das Abhängigkeitsdiagramm zeigt nur eine Instanz jeder Manifestdatei mithilfe der folgenden Rangfolgeregeln an.

1.        **Benutzerübermittlungen** haben die höchste Priorität, da sie in der Regel während des Erstellens von Artefakten entstehen und die vollständigsten Informationen enthalten.
   

   • Wenn mehrere manuelle Momentaufnahmen aus verschiedenen Detektoren vorhanden sind, werden sie alphabetisch nach Korrelator und dem ersten verwendeten sortiert.
   • Wenn es zwei Korrelatoren mit demselben Detektor gibt, werden die aufgelösten Abhängigkeiten zusammengeführt. Weitere Informationen zu Korrelatoren und Detektoren findest du unter REST-API-Endpunkte für die Abhängigkeitsübermittlung.

2.        **Automatische Übermittlungen** haben die zweithöchste Priorität, da sie auch während der Artefaktbuilds erstellt werden, aber nicht von Benutzern übermittelt werden.
   

3.        **Statische Analyseergebnisse** werden verwendet, wenn keine anderen Daten verfügbar sind.
   

Ökosystemspezifische Informationen des Pakets

Maven-Projekte

Bei Maven-Projekten führt die automatische Abhängigkeitsübermittlung einen Open-Source-Fork von Maven Dependency Tree Dependency Submission aus. Durch den Fork kann GitHub mit dem Upstreamrepository synchronisiert bleiben und einige Änderungen beibehalten, die nur für die automatische Übermittlung gelten. Die Quelle des Forks ist unter advanced-security/maven-dependency-submission-action verfügbar.

Wenn die Abhängigkeiten deines Repositorys nicht korrekt erscheinen, überprüfe, ob der Zeitstempel des letzten Abhängigkeitsdiagrammbuilds mit der letzten Änderung deiner pom.xml-Datei übereinstimmt. Der Zeitstempel ist in der Tabelle der Warnungen auf der Registerkarte „Dependabot alerts“ des Repositorys sichtbar. Durch das Pushen eines Commits, der pom.xml aktualisiert, wird eine neue Ausführung der Aktion „Dependency Tree Submission“ ausgelöst und eine Neuerstellung des Abhängigkeitsdiagramms dieses Repositorys erzwungen.

Gradle-Projekte

Bei Gradle-Projekten führt die automatische Abhängigkeitsübermittlung einen Fork der Open-Source-Aktionen unter gradle/actions aus. Der Fork ist unter actions/gradle-build-tools-actions verfügbar. Du kannst die Ergebnisse der Aktion für die automatische Bereitstellung auf der Registerkarte Actions deines Repositorys einsehen. Jede Ausführung wird als „Automatic Dependency Submission (Gradle)“ bezeichnet, und ihre Ausgabe enthält die JSON-Nutzdaten, die die Aktion an die API übermittelt hat.

.NET Projekte

Die automatische .NET-Einreichungsaktion verwendet das Open-Source-Projekt component-detection als Engine für die Abhängigkeitserkennung. Es unterstützt .NET 8.x, 9.x und 10.x. Die .NET-Autosubmission wird ausgeführt, wenn das Repository dependabot.yml als ein nuget definiert package-ecosystem oder wenn sich im Stammverzeichnis des Repositorys eine unterstützte Manifestdatei befindet. Zu den unterstützten Manifestdateien gehören .sln, .csproj, packages.config, .vbproj, .vcxprojund .fsproj.

Python Projekte

Python verwendet das projekt open source component-detection als zugrunde liegendes Diagrammgenerierungsmodul. Die Aktion "Automatisches Senden" für Python wird nur ausgeführt, wenn im Stammverzeichnis des Repositorys eine datei requirements.txt vorhanden ist. Python-Autoübermittlung unterstützt derzeit keine privaten Pakete. Pakete, auf die in requirements.txt verwiesen wird und die nicht öffentlich verfügbar sind, führen dazu, dass die Autoübermittlung fehlschlägt.