Envoi automatique des dépendances

Configurer l’accès réseau pour les exécuteurs auto-hébergés

Si vos exécuteurs auto-hébergés fonctionnent derrière un pare-feu avec un accès Internet sortant restreint, vous devez ajouter certaines URL à la liste d’autorisations pour l’envoi automatique des dépendances. Les URL requises dépendent des écosystèmes utilisés par vos référentiels.

URL requises pour tous les écosystèmes

Ces URL sont requises pour tous les flux de travail de soumission de dépendances automatiques :

• https://github.com— Obligatoire pour accéder aux GitHub actions et les télécharger.
• https://api.github.com— Obligatoire pour GitHub l’accès à l’API.
• https://*.githubusercontent.com— Requis pour télécharger le code source et les versions d’action (y compris raw.githubusercontent.com, github-releases.githubusercontent.comet objects.githubusercontent.com).

URL spécifiques à l’écosystème

Selon les écosystèmes que vous utilisez, vous devrez peut-être ajouter des URL supplémentaires à la liste d’autorisations.

Allez

• https://go.dev— Pour télécharger la chaîne d’outils Go.
• https://golang.org— Autre domaine pour les téléchargements Go.
• https://proxy.golang.org— Proxy de module Go officiel pour le téléchargement des modules Go lors de la détection des dépendances.

Java (Maven et Gradle)

• https://repo.maven.apache.org— Référentiel Maven Central pour le téléchargement des dépendances.
• https://api.adoptium.net— Pour télécharger les distributions JDK Adoptium/Temurin (distribution par défaut utilisée par actions/setup-java).

Pour les projets Gradle, vous devez également accéder au portail du plug-in Gradle, où l’action de soumission automatique télécharge par github-dependency-graph-gradle-plugin défaut :

• https://plugins.gradle.org— Sert le marqueur de plug-in et maven-metadata.xml.
• https://plugins-artifacts.gradle.org— Sert les métadonnées POM, module et JAR du plug-in. Le portail de plug-in Gradle redirige les téléchargements d’artefacts vers cet hôte. Ainsi, la liste verte résout uniquement plugins.gradle.org les métadonnées, puis échoue lorsque l’artefact du plug-in est téléchargé.

Si vos exécuteurs ne peuvent pas atteindre le portail du plug-in Gradle ou que vous souhaitez éviter en fonction des hôtes qui peuvent changer au fil du temps, résolvez le plug-in à partir d’un référentiel interne que vous contrôlez à la place. Pour plus d’informations, consultez les projets Gradle.

Si vous utilisez une autre distribution JDK, vous pouvez également avoir besoin des éléments suivants :

• https://aka.ms et https://download.microsoft.com : pour Build Microsoft d’OpenJDK (remarque : aka.ms est également utilisé pour les téléchargements .NET).
• https://download.oracle.com— Pour le JDK Oracle.
• https://api.azul.com— Pour Azul Zulu OpenJDK.

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

• https://aka.ms : raccourcisseur d’URL Microsoft qui redirige vers des emplacements de téléchargement .NET.
• https://builds.dotnet.microsoft.com : flux principal pour .NET sdk et téléchargements d’exécution.
• https://ci.dot.net : flux secondaire pour les builds .NET.

Python

• https://python.org : pour télécharger des interpréteurs Python.

Utiliser un service GitHub hébergé exécuteurs plus grands pour la soumission automatique de dépendances

Les utilisateurs de GitHub Team ou GitHub Enterprise Cloud peuvent utiliser exécuteurs plus grands pour exécuter des travaux de soumission automatique des dépendances.

1. Approvisionnez un exécuteur plus grand au niveau de l’organisation avec le nom dependency-submission. Pour plus d’informations, consultez Ajout d'une exécuteur plus grand à une organisation.
2. Donnez à votre dépôt l’accès à l’exécuteur. Pour plus d’informations, consultez Autorisation d'accès pour les dépôts exécuteurs plus grands.
3. Sous « Graphique des dépendances », cliquez sur le menu déroulant en regard d’« Envoi automatique des dépendances », puis sélectionnez Activé pour les exécuteurs étiquetés.

Résoudre les problèmes de soumission automatique des dépendances

L’envoi automatique de dépendances s’efforce de mettre en cache les téléchargements de packages entre les exécutions à l’aide de l’action Mettre en cache pour accélérer les flux de travail. Pour les exécuteurs auto-hébergés, vous pouvez gérer ce cache au sein de votre propre infrastructure. Pour ce faire, vous pouvez désactiver la mise en cache intégrée en définissant une variable d’environnement de GH_DEPENDENCY_SUBMISSION_SKIP_CACHE sur true. Pour plus d’informations, consultez « Stocker des informations dans des variables ».

Déduplication du manifeste

Un référentiel peut utiliser plusieurs méthodes pour la soumission de dépendances, ce qui peut entraîner l’analyse du même manifeste de package plusieurs fois, potentiellement avec des sorties différentes de chaque analyse. Le graphe des dépendances utilise une logique de déduplication pour analyser les sorties, en donnant la priorité aux informations les plus précises pour chaque fichier manifeste.

Le graphe des dépendances affiche uniquement une instance de chaque fichier manifeste à l’aide des règles de priorité suivantes.

1. Les soumissions des utilisateurs ont la priorité absolue, car elles sont généralement créées lors de la génération des artefacts et contiennent donc les informations les plus complètes.
   • S’il existe plusieurs instantanés manuels provenant de différents détecteurs, ils sont classés par ordre alphabétique selon le corrélateur et le premier est utilisé.
   • S’il existe deux corrélateurs avec le même détecteur, les dépendances résolues sont fusionnées. Pour plus d’informations sur les corrélateurs et les détecteurs, consultez Points de terminaison d’API REST pour la soumission de dépendances.
2. ** Dependabot Les travaux de graphe** ont la deuxième priorité la plus élevée. Pour les écosystèmes où Dependabot les travaux de graphe sont disponibles (actuellement Go et Python), ils sont prioritaires par rapport à la soumission automatique de dépendances.
3. Les soumissions automatiques ont la priorité suivante, car elles sont également créées pendant les builds d’artefacts, mais ne sont pas soumises par les utilisateurs.
4. Les résultats de l’analyse statique sont utilisés lorsqu’aucune autre donnée n’est disponible.

Informations spécifiques à l’écosystème de packages

Projets Maven

Pour les projets Maven, l’envoi automatique des dépendances exécute une duplication (fork) open source de l’envoi des dépendances de l’arborescence des dépendances Maven. Le fork permet GitHub de rester synchronisé avec le référentiel en amont et de plus, de conserver certaines modifications qui ne concernent que la soumission automatique. La source de la duplication (fork) est disponible à l’adresse advanced-security/maven-dependency-submission-action.

Si les dépendances de votre dépôt semblent inexactes, vérifiez que le timestamp de la génération la plus récente du graphique des dépendances correspond à la modification la plus récente de votre fichier pom.xml. L’horodatage est visible dans la table des alertes dans l'onglet Dependabot du référentiel. Pousser une validation qui met à jour pom.xml déclenchera une nouvelle exécution de l’action de soumission de l’arborescence de dépendances et forcera une reconstruction du graphe de dépendances de ce référentiel.

Projets Gradle

Pour les projets Gradle, la soumission automatique de dépendances exécute un fork des actions open source de Gradle à partir de gradle/actions. La duplication (fork) est disponible à l’adresse actions/gradle-build-tools-actions. Vous pouvez afficher les résultats de l’action d’envoi automatique sous l’onglet Actions de votre dépôt. Chaque exécution est étiquetée « Envoi automatique des dépendances (Gradle) » et sa sortie contient la charge utile JSON que l’action a envoyée à l’API.

Résolution du plug-in de soumission à partir d’un référentiel interne

Par défaut, l’action télécharge à github-dependency-graph-gradle-plugin partir du portail du plug-in Gradle (https://plugins.gradle.org). Pour les exécuteurs auto-hébergés sur un réseau restreint, l’hébergement du plug-in dans un référentiel interne que vous contrôlez, tel qu’une instance d’Artefactory privée ou Nexus, est plus fiable que la liste verte du portail, dont les hôtes et les CDN peuvent changer au fil du temps. Vous pouvez pointer l’action sur votre référentiel interne avec ces variables d’environnement :

• GRADLE_PLUGIN_REPOSITORY_URL: URL du référentiel interne à partir de laquelle résoudre le plug-in.
• GRADLE_PLUGIN_REPOSITORY_USERNAME et GRADLE_PLUGIN_REPOSITORY_PASSWORD— Informations d’identification, si le référentiel requiert l’authentification.

La soumission automatique de dépendances exécute un flux de travail qui GitHub gère, et non un que vous créez dans votre référentiel, de sorte que vous ne pouvez pas y ajouter un env: bloc. Vous pouvez définir ces variables sur l’exécuteur, mais chaque travail planifié sur cet exécuteur, non seulement les travaux de soumission de dépendance automatique, les hérite.

Si votre référentiel interne autorise l’accès en lecture anonyme, vous devez uniquement définir GRADLE_PLUGIN_REPOSITORY_URL et omettre entièrement les variables d’informations d’identification, ce qui évite cette préoccupation. Si le référentiel nécessite une authentification, utilisez des informations d’identification en lecture seule et un exécuteur dédié. Pour les exécuteurs au niveau de l’organisation ou de l’entreprise, limitez également l’accès au groupe d’exécuteurs uniquement aux référentiels qui ont besoin de ces informations d’identification. Consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes ».

La résolution du plug-in à partir d’un référentiel interne est distincte de la configuration de la façon dont votre build résout ses propres dépendances, par exemple un init.gradle fichier qui pointe vers un registre interne. Ces variables contrôlent uniquement l’emplacement à partir duquel le plug-in de soumission de dépendances est téléchargé.

Pour plus d’informations sur la configuration, consultez la documentation actions/gradle-build-tools-actions .

projets .NET

L’action de soumission automatique .NET utilise le projet open source component-detection comme moteur pour sa détection de dépendances. Il prend en charge .NET 8.x, 9.x et 10.x. L’envoi automatique .NET s’exécute si le dependabot.yml du dépôt définit nuget comme package-ecosystem ou si un fichier manifeste pris en charge se trouve dans le répertoire racine du dépôt. Les fichiers manifeste pris en charge incluent .sln, .csproj, packages.config, .vbproj, .vcxproj et .fsproj.

projets Python

Les référentiels Python avec le graphique de dépendance activé utilisent des tâches de graphe pour générer des graphiques de dépendance. Dependabot Les travaux de graphe sont prioritaires sur les soumissions de dépendances automatiques, et le flux de travail de soumission automatique décrit ci-dessous ne s’exécute plus pour les projets Python. Pour plus d’informations, consultez « Comment le graphique de dépendances reconnaît les dépendances ».

La soumission automatique de dépendances pour Python utilise le projet de détection des composants open source comme moteur de génération de graphique sous-jacent. L’action de soumission automatique s’exécute uniquement s’il existe un requirements.txt fichier dans le répertoire racine du référentiel. Python la soumission automatique ne prend actuellement pas en charge les packages privés ; les packages référencés dans requirements.txt qui ne sont pas disponibles publiquement entraînent l’échec de l’action de soumission automatique.