Skip to main content

À propos des mises à jour de version Dependabot

Vous pouvez utiliser Dependabot pour maintenir les packages que vous utilisez à jour aux dernières versions.

Les Dependabot version updates gratuites à l’utilisation pour tous les référentiels sur GitHub.com.

À propos des Dependabot version updates

Dependabot s’efforce de maintenir vos dépendances. Vous pouvez l’utiliser pour vous assurer que votre dépôt reçoit automatiquement les dernières versions des packages et des applications dont il dépend.

Vous activez les Dependabot version updates en archivant un fichier de configuration dependabot.yml dans votre référentiel. Le fichier de configuration spécifie l’emplacement du manifeste, ou d’autres fichiers de définition de package, stockés dans votre dépôt. Dependabot utilise ces informations pour rechercher les packages et applications obsolètes. Dependabot détermine s’il existe une nouvelle version d’une dépendance en examinant le versioning sémantique (semver) de celle-ci. Il peut ainsi décider s’il est nécessaire de mettre à jour la dépendance vers cette version. Pour certains gestionnaires de packages, les Dependabot version updates prennent également en charge le placement dans le répertoire vendor. Les dépendances placées dans le répertoire vendor (ou mises en cache) sont des dépendances qui sont archivées dans un répertoire spécifique au sein d’un dépôt plutôt que référencées dans un manifeste. Les dépendances placées dans le répertoire vendor sont disponibles au moment de la génération, même si les serveurs de package ne sont pas disponibles. Les Dependabot version updates peuvent être configurées pour vérifier s’il existe de nouvelles versions pour les dépendances placées dans le répertoire vendor et mettre celles-ci à jour si nécessaire.

Quand Dependabot identifie une dépendance obsolète, il déclenche une demande de tirage (pull request) pour mettre à jour le manifeste vers la dernière version de la dépendance. Pour les dépendances placées dans le répertoire vendor, Dependabot déclenche une demande de tirage pour remplacer la dépendance obsolète par la nouvelle version directement. Vous vérifiez que vos tests réussissent, passez en revue le journal des modifications et les notes de publication incluses dans le résumé de la demande de tirage, puis vous la fusionnez. Pour plus d’informations, consultez « Configuration de mises à jour de version Dependabot ».

Si vous activez les mises à jour de sécurité, Dependabot déclenche également des demandes de tirage pour mettre à jour les dépendances vulnérables. Pour plus d’informations, consultez « À propos des mises à jour de sécurité Dependabot ».

Quand Dependabot déclenche des demandes de tirage, celles-ci peuvent concerner des mises à jour de sécurité ou de version :

  • Les Dependabot security updates sont des demandes de tirage automatisées qui vous aident à mettre à jour les dépendances qui ont des vulnérabilités connues.
  • Les Dependabot version updates sont des demandes de tirage automatisées qui tiennent à jour les dépendances, même si elles ne présentent aucune vulnérabilité. Pour vérifier l’état des mises à jour de version, accédez à l’onglet Insights de votre dépôt, puis sélectionnez Dependency Graph et Dependabot.

GitHub Actions n’est pas indispensable à l’exécution des Dependabot version updates et des Dependabot security updates sur GitHub Enterprise Cloud. Toutefois, les demandes de tirage ouvertes par Dependabot peuvent déclencher des workflows qui exécutent des actions. Pour plus d’informations, consultez « Automatisation de Dependabot avec GitHub Actions ».

Dependabot et toutes les fonctionnalités associées sont couverts par votre contrat de licence. Pour plus d’informations, consultez « GitHub Conditions d’utilisation de client entreprise ».

Fréquence des demandes de tirage Dependabot

Vous spécifiez la fréquence à laquelle vérifier chaque écosystème pour déterminer s’il existe de nouvelles versions dans le fichier de configuration : quotidienne, hebdomadaire ou mensuelle.

Lorsque vous activez les mises à jour de version pour la première fois, vous pouvez avoir de nombreuses dépendances obsolètes et certaines peuvent remonter à de nombreuses versions avant la dernière version. Dependabot recherche les dépendances obsolètes dès qu’il est activé. Vous pouvez voir de nouvelles demandes de tirage pour les mises à jour de version dans les minutes qui suivent l’ajout du fichier de configuration, en fonction du nombre de fichiers manifeste pour lesquels vous configurez les mises à jour. Dependabot exécute également une mise à jour sur les modifications suivantes apportées au fichier de configuration.

Dependabot peut également créer des demandes de tirage lorsque vous modifiez un fichier manifeste une fois qu’une mise à jour a échoué. Cela est dû au fait que les modifications apportées à un manifeste, telles que la suppression de la dépendance qui a provoqué l’échec de la mise à jour, peuvent entraîner la réussite de la mise à jour nouvellement déclenchée.

Pour que les demandes de tirage restent faciles à gérer et à réviser, Dependabot déclenche un maximum de cinq demandes de tirage pour commencer à mettre les dépendances à niveau vers la version la plus récente. Si vous fusionnez certaines de ces premières demandes de tirage avant la prochaine mise à jour planifiée, les demandes de tirage restantes seront ouvertes au cours de la prochaine mise à jour, jusqu’à ce maximum. Vous pouvez modifier le nombre maximal de demandes de tirage ouvertes en définissant l’option de configuration open-pull-requests-limit.

Pour réduire davantage le nombre de demandes de tirage que vous pouvez voir, vous pouvez utiliser l’option de configuration groups pour grouper des ensembles de dépendances (par écosystème de packages). Dependabot déclenche ensuite une demande de tirage unique pour mettre à jour le plus de dépendances possible dans le groupe vers les versions les plus récentes en même temps. Pour plus d’informations, consultez « Personnalisation des mises à jour des dépendances ».

Si vous avez activé les mises à jour de sécurité, vous voyez parfois des demandes de tirage supplémentaires pour les mises à jour de sécurité. Celles-ci sont déclenchées par une alerte Dependabot pour une dépendance sur votre branche par défaut. Dependabot déclenche automatiquement une demande de tirage pour mettre à jour la dépendance vulnérable.

Parfois, en raison d’une configuration incorrecte ou d’une version incompatible, vous pouvez voir qu’une exécution de Dependabot a échoué. Après 30 exécutions en échec, Dependabot version updates va ignorer les exécutions planifiées suivantes jusqu’à ce que vous déclenchiez manuellement une recherche des mises à jour à partir du graphe des dépendances, ou que vous mettiez à jour le fichier manifeste. Dependabot security updates va néanmoins toujours s’exécuter comme d’habitude.

Dépôts et écosystèmes pris en charge

Vous pouvez configurer les mises à jour de version pour les dépôts qui contiennent un fichier de verrouillage ou manifeste de dépendance pour l’un des gestionnaires de packages pris en charge. Pour certains gestionnaires de packages, vous pouvez également configurer le placement dans le répertoire vendor pour les dépendances. Pour plus d’informations, consultez « Options de configuration pour le fichier dependabot.yml ».

Remarque : Lors de l’exécution de mises à jour de sécurité ou de version, certains écosystèmes doivent être capables de résoudre toutes les dépendances de leur source pour vérifier que les mises à jour ont réussi. Si vos fichiers manifeste ou de verrouillage contiennent des dépendances privées, Dependabot doit être capable d’accéder à l’emplacement auquel ces dépendances sont hébergées. Les propriétaires de l’organisation peuvent octroyer à Dependabot un accès aux dépôts privés contenant des dépendances pour un projet au sein de cette même organisation. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre organisation ». Vous pouvez configurer un accès aux registres privés dans le fichier de configuration dependabot.yml d’un dépôt. Pour plus d’informations, consultez « Options de configuration pour le fichier dependabot.yml ».

Dependabot ne prend pas en charge les dépendances GitHub privées pour tous les gestionnaires de package. Pour plus d’informations, consultez le tableau ci-dessous.

Pour chaque gestionnaire de package, le tableau suivant montre ce qui suit :

  • Valeur YAML à utiliser dans le fichier dependabot.yml
  • Versions prises en charge du gestionnaire de package
  • Indique si les dépendances des référentiels et registres privés GitHub sont pris en charge
  • Indique si les dépendances fournisseur sont prises en charge
Gestionnaire de packageValeur YAMLVersions prises en chargeRéférentiels privésRegistres privésVendoring
Bundlerbundlerv1, v2
Cargocargov1 (git uniquement)
Composercomposerv1, v2
Dockerdockerv1Non applicable
Hexmixv1
elm-packageelmv0.19
sous-module gitgitsubmoduleNon applicableNon applicable
GitHub Actionsgithub-actionsNon applicableNon applicable
Modules Gogomodv1
GradlegradleNon applicable
MavenmavenNon applicable
npmnpmv6, v7, v8, v9
NuGetnuget<= 4.8
pippipv21.1.2
pipenvpip<= 2021-05-29
pip-compilepip6.1.0
pnpmnpmv7, v8
poetrypipv1
bistrotpubv2
Swiftswiftv5 (git uniquement)
Terraformterraform>= 0.13, <= 1.5.xNon applicable
yarnnpmv1, v2, v3

Conseil : pour les gestionnaires de package tels que pipenv et poetry, vous devez utiliser la valeur YAML pip. Par exemple, si vous utilisez poetry pour gérer vos dépendances Python et que vous souhaitez que Dependabot surveille votre fichier manifeste de dépendance pour les nouvelles versions, utilisez package-ecosystem: "pip" dans votre fichier dependabot.yml.

Cargo

La prise en charge des registres privés s’applique aux registres git et n’inclut pas les registres cargo.

Docker

Dependabot peut ajouter des métadonnées à partir d’images Docker aux demandes de tirage pour les mises à jour de version. Les métadonnées incluent les notes de publication, les journaux de modifications et l’historique des validations. Les administrateurs de référentiels peuvent utiliser les métadonnées pour évaluer rapidement le risque de stabilité de la mise à jour des dépendances.

Pour que Dependabot récupère les métadonnées Docker, les responsables de la maintenance des images Docker doivent ajouter l’étiquette org.opencontainers.image.source à leur fichier Dockerfile et inclure l’URL du référentiel source. Par ailleurs, les responsables doivent étiqueter le référentiel avec les mêmes étiquettes que les images Docker publiées. Pour obtenir un exemple, consultez le référentiel dependabot-fixtures/docker-with-source. Pour plus d’informations sur les étiquettes Docker, consultez Étiquettes d’image d’extension et BUILDX_GIT_LABELS dans la documentation Docker.

Dependabot peut mettre à jour les étiquettes d’images Docker dans les manifestes Kubernetes. Ajoutez une entrée à l’élément Docker package-ecosystem de votre fichier dependabot.yml pour chaque répertoire contenant un manifeste Kubernetes qui fait référence à des étiquettes d’images Docker. Les manifestes Kubernetes peuvent être des fichiers YAML de déploiement Kubernetes ou des graphiques Helm. Pour plus d’informations sur la configuration de votre fichier dependabot.yml pour docker, consultez « package-ecosystem » dans « Options de configuration pour le fichier dependabot.yml ».

Dependabot prend en charge les registres Docker publics et privés. Pour obtenir la liste des registres pris en charge, consultez « docker-registry » dans « Options de configuration pour le fichier dependabot.yml ».

GitHub Actions

Dependabot prend uniquement en charge les mises à jour pour GitHub Actions avec la syntaxe du dépôt GitHub, comme actions/checkout@v4. Les URL Docker Hub et GitHub Packages Container registry ne sont actuellement pas prises en charge.

Dependabot prend en charge les référentiels publics et privés pour GitHub Actions. Pour connaître les options de configuration du registre privé, consultez « git » dans « Options de configuration pour le fichier dependabot.yml ».

Gradle

Dependabot n’exécute pas Gradle, mais prend en charge les mises à jour vers les fichiers suivants :

  • build.gradle, build.gradle.kts (pour les projets Kotlin)
  • gradle/libs.versions.toml (pour les projets utilisant un catalogue de versions Gradle standard)
  • Les fichiers inclus via la déclaration apply qui ont dependencies dans le nom de fichier. Notez que apply ne prend pas en charge apply to, la récursivité ou les syntaxes avancées (par exemple, les noms de fichier apply avec mapOf Kotlin définis par propriété).

Pour Dependabot security updates, la prise en charge de Gradle est limitée aux chargements manuels des données du graphique de dépendance à l’aide de l’API de soumission de dépendances. Pour plus d’informations sur l’API de soumission de dépendances, consultez « Utilisation de l’API de soumission de dépendances ».

Note : lorsque vous chargez des dépendances Gradle dans le graphique de dépendances à l’aide de l’API de soumission de dépendances, toutes les dépendances de projet sont chargées, même les dépendances indirectes qui ne sont pas explicitement mentionnées dans un fichier de dépendances. Lorsqu’une alerte est détectée dans une dépendance indirecte, Dependabot n’est pas en mesure de trouver la dépendance vulnérable dans le référentiel et ne crée donc pas de mise à jour de sécurité pour cette alerte.

Maven

Dependabot n’exécute pas Maven, mais prend en charge les mises à jour des fichiers pom.xml.

Interface de ligne de commande NuGet

Dependabot n’exécute pas l’interface CLI NuGet, mais prend en charge la plupart des fonctionnalités jusqu’à la version 4.8.

pip et pip-compile

En plus de prendre en charge les mises à jour des fichiers requirements.txt, Dependabot prend en charge les mises à jour des fichiers pyproject.toml s’ils respectent le standard PEP 621.

pnpm

pnpm est pris en charge pour Dependabot version updates et Dependabot security updates.

bistrot

Dependabot n’effectue pas de mise à jour pour pub quand la version vers laquelle il tente d’opérer la mise à jour est ignorée, même si une version antérieure est disponible.

Swift

La prise en charge du registre privé s’applique uniquement aux registres Git. Les registres Swift ne sont pas pris en charge. Les manifestes non déclaratifs ne sont pas pris en charge. Pour plus d’informations sur les manifestes non déclaratifs, consultez Modification de manifestes non déclaratifs dans la documentation Swift Evolution.

yarn

Dependabot prend en charge les dépendances fournisseur pour les versions v2 et ultérieures.

Si votre dépôt utilise déjà une intégration pour la gestion des dépendances, vous devez la désactiver avant d’activer Dependabot. Pour plus d’informations, consultez « À propos de l’utilisation des intégrations ».

À propos de la désactivation automatique des Dependabot updates

Lorsque les mainteneurs d’un dépôt cessent d’interagir avec les demandes de tirage Dependabot, Dependabot suspend temporairement ses mises à jour et vous en informe. Ce comportement de désactivation automatique réduit les actions inutiles parce que Dependabot ne crée pas de demandes de tirage pour les mises à jour de version et de sécurité, ni ne rebase les demandes de tirage Dependabot pour les dépôts inactifs.

La désactivation automatique des mises à jour de Dependabot s’applique uniquement aux dépôts où Dependabot a ouvert des demandes de tirage mais celles-ci restent inchangées. Si Dependabot n’a pas ouvert de demandes de tirage, Dependabot ne sera jamais suspendu.

Un dépôt actif est un dépôt pour lequel un utilisateur (et non Dependabot) a effectué l’une des actions ci-dessous au cours des 90 derniers jours :

  • Fusionnez ou fermez une demande de tirage Dependabot sur le dépôt.
  • Apportez une modification au fichier dependabot.yml pour le dépôt.
  • Déclenchez manuellement une mise à jour de sécurité ou une mise à jour de version.
  • Activez les Dependabot security updates pour le dépôt.
  • Utilisez les commandes @dependabot sur les demandes de tirage.

Un dépôt inactif est un dépôt qui a au moins une demande de tirage Dependabot ouverte pendant plus de 90 jours, qui a été activée pendant toute la période et où aucune des actions listées ci-dessus n’a été effectuée par un utilisateur.

Lorsque Dependabot est suspendu, GitHub ajoute une notification au corps de toutes les demandes de tirage Dependabot ouvertes et affecte une étiquette dependabot-paused à ces demandes de tirage. Vous verrez également une bannière dans l’interface utilisateur de l’onglet Paramètres du référentiel (sous Sécurité et analyse du code, puis Dependabot ), ainsi que dans la liste des Dependabot alerts (if Dependabot security updates sont affectés). De plus, vous pourrez savoir si Dependabot est suspendu au niveau de l’organisation dans la vue d’ensemble de la sécurité. L’état paused sera également visible via l’API. Pour plus d’informations, consultez « Référentiels » dans la documentation de l’API REST.

Dès qu’un mainteneur interagit à nouveau avec une demande de tirage Dependabot, Dependabot sort de sa suspension :

  • Les mises à jour de sécurité sont automatiquement reprises pour les Dependabot alerts.
  • Les mises à jour de version sont automatiquement reprises avec la planification spécifiée dans le fichier dependabot.yml.

Dependabot arrête également le rebasage des demandes de tirage pour les mises à jour de version et de sécurité après 30 jours, réduisant ainsi les notifications liées aux demandes de tirage Dependabot inactives.

À propos des notifications pour les mises à jour de version Dependabot

Vous pouvez filtrer vos notifications sur GitHub pour afficher les notifications des demandes de tirage créées par Dependabot. Pour plus d’informations, consultez « Gestion des notifications à partir de votre boîte de réception ».