# Optimisation de la création de requêtes de tirage pour les mises à jour de version Dependabot Découvrez comment rationaliser et gérer efficacement vos Dependabot pull requests. Par défaut, Dependabot ouvre une nouvelle pull request pour mettre à jour chaque dépendance. Lorsque vous activez les mises à jour de sécurité, de nouvelles demandes d’extraction sont ouvertes lorsqu’une dépendance vulnérable est détectée. Lorsque vous configurez les mises à jour de version pour un ou plusieurs écosystèmes, de nouvelles demandes d’extraction sont ouvertes lorsque de nouvelles versions des dépendances sont disponibles, à la fréquence définie dans le fichier `dependabot.yml`. Si votre projet a de nombreuses dépendances, vous pouvez constater que vous disposez d’un très grand nombre de pull requests à réviser et à fusionner, ce qui peut rapidement devenir difficile à gérer. Il existe plusieurs options de customisation que vous pouvez implémenter pour optimiser les Dependabot pull requests de mise à jour afin de les aligner sur vos processus, par exemple : * **Contrôle de la fréquence** avec laquelle Dependabot vérifie les versions plus récentes de vos dépendances avec `schedule`. * **Priorité aux mises à jour significatives** avec `groups`. ## Contrôle de la fréquence et du moment des mises à jour des dépendances ``` Dependabotexécute ses vérifications pour les mises à jour de version à une fréquence définie par vous dans le fichier de configuration, où le champ requis, doit `schedule.interval`être défini sur `daily`, , , `weekly``monthly`, `quarterly`, `semiannually`, , `yearly`ou `cron` (voir [`cronjob`](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cronjob)). ``` Par défaut, Dependabot équilibre sa charge de travail en assignant un délai aléatoire pour vérifier et soumettre des pull requests pour les mises à jour des dépendances. Toutefois, afin de réduire les distractions ou de mieux organiser le temps et les ressources nécessaires à l’examen et au traitement des mises à jour de version, il pourrait être utile de modifier la fréquence et le calendrier. Par exemple, vous pouvez préférer exécuter Dependabot des vérifications hebdomadaires plutôt que des vérifications quotidiennes des mises à jour, et à un moment qui garantit que les pull requests sont déclenchées avant la session de triage de votre équipe. ### Modification de la fréquence et des délais pour les mises à jour des dépendances Vous pouvez utiliser `schedule` avec une combinaison d'options pour modifier la fréquence et le moment où Dependabot vérifie les mises à jour de version. L’exemple `dependabot.yml` de fichier ci-dessous modifie la configuration npm pour spécifier que Dependabot doit vérifier les mises à jour de version des dépendances npm tous les mardis à 02h00 heure standard japonaise (UTC +09:00). ```yaml copy # `dependabot.yml` file with # customized schedule for version updates version: 2 updates: # Keep npm dependencies up to date - package-ecosystem: "npm" directory: "/" # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00) schedule: interval: "weekly" day: "tuesday" time: "02:00" timezone: "Asia/Tokyo" ``` Consultez également [planification](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-). ### Configuration d’une période d’attente pour les mises à jour des dépendances Vous pouvez utiliser `cooldown` avec une combinaison d’options pour contrôler quand Dependabot crée des pull requests pour les **mises à jour de version**, mais pas les **mises à jour de sécurité**. Le fichier d’exemple `dependabot.yml` ci-dessous montre une période de refroidissement appliquée aux dépendances `requests`, `numpy`, et celles précédées de `pandas` ou de `django`, mais pas à la dépendance appelée `pandas` (correspondance exacte), qui est exclue via la liste **exclure**. ```yaml copy version: 2 updates: - package-ecosystem: "pip" directory: "/" schedule: interval: "daily" cooldown: default-days: 5 semver-major-days: 30 semver-minor-days: 7 semver-patch-days: 3 include: - "requests" - "numpy" - "pandas*" - "django" exclude: - "pandas" ``` * Le nombre de jours de délai doit être compris entre 1 et 90. * La limite maximale autorisée pour les éléments des listes `include` et `exclude`, qui peuvent être utilisées avec `cooldown`, est de 150 pour chacune. > \[!NOTE] > Pour prendre en compte **toutes les dépendances** pour une période de refroidissement, vous pouvez : > > * Omettez l’option `include` qui applique un délai d’attente à toutes les dépendances. > * Utilisez `"*"` dans `include` pour appliquer les paramètres de délai d’attente à l’ensemble des éléments. > Nous vous recommandons d’utiliser `exclude` pour **uniquement** exclure des **dépendances spécifiques** des paramètres de refroidissement. SemVer est pris en charge par la plupart des gestionnaires de packages. Les mises à jour vers les nouvelles versions pour les dépendances en attente sont reportées comme suit : * Mises à jour majeures : retardées de 30 jours (`semver-major-days: 30`). * Mises à jour mineures : retardées de 7 jours (`semver-minor-days: 7`). * Mises à jour correctives : retardées de 3 jours (`semver-patch-days: 3`). Voir aussi [`cooldown`](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-). ## Priorité aux mises à jour significatives ### Regroupement des dépendances associées Vous pouvez utiliser `groups` pour regrouper les mises à jour de plusieurs dépendances dans une seule demande de tirage. Cela vous permet de concentrer votre temps de révision sur les mises à jour à haut risque et de minimiser le temps consacré à la révision des mises à jour mineures. Par exemple, vous pouvez regrouper les mises à jour mineures ou les correctifs pour les dépendances de développement dans une seule pull request, et disposer d’un groupe dédié aux mises à jour de sécurité ou de version qui ont un impact sur un domaine clé de votre base de code. Il est nécessaire de configurer des groupes par écosystème de packages individuel, puis vous pouvez créer plusieurs groupes par écosystème de packages en utilisant une combinaison de critères : * Dependabot type de mise à jour : `applies-to` * Type de dépendance : `dependency-type`. * Nom de dépendance : `patterns` et `exclude-patterns` * Niveaux de version sémantique : `update-types` Pour afficher toutes les valeurs prises en charge pour chaque critère, consultez [`groups`](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--). Les exemples ci-dessous présentent plusieurs méthodes différentes pour créer des groupes de dépendances à l’aide des critères. ### Exemple 1 : Trois groupes de mise à jour des versions Dans cet exemple, le`dependabot.yml` fichier : * Créez trois groupes, appelés «`production-dependencies`», «`development-dependencies`» et «`rubocop`». * Utilisez `patterns` et `dependency-type` pour inclure des dépendances dans le groupe. * Utilisez `exclude-patterns` pour exclure une dépendance (ou plusieurs dépendances) du groupe. ```yaml version: 2 updates: # Keep bundler dependencies up to date - package-ecosystem: "bundler" directory: "/" schedule: interval: "weekly" groups: production-dependencies: dependency-type: "production" development-dependencies: dependency-type: "development" exclude-patterns: - "rubocop*" rubocop: patterns: - "rubocop*" ``` Par conséquent : * Les mises à jour de version sont regroupées par type de dépendance. * Les dépendances de développement correspondant au modèle `rubocop*` sont exclues du groupe `development-dependencies` . * Au lieu de cela, les dépendances de développement correspondant `rubocop*` seront incluses dans le groupe `rubocop`. En raison de la commande, la correspondance des dépendances de production`rubocop*` sera incluse dans le groupe `production-dependencies`. * Qui plus est, tous les groupes s’appliquent par défaut aux mises à jour de version uniquement, car la clé `applies-to` est absente. ### Exemple 2 : Mises à jour groupées avec dépendances exclues Dans cet exemple, le`dependabot.yml` fichier : * Créez un groupe appelé « `support-dependencies` », dans le cadre d’une configuration Bundler personnalisée. * Utilisez `patterns` qui correspond au nom d’une dépendance (ou plusieurs dépendances) pour inclure des dépendances dans le groupe. * Utilisez `exclude-patterns` qui correspond au nom d’une dépendance (ou plusieurs dépendances) pour exclure les dépendances du groupe. * Appliquez le regroupement aux mises à jour de version uniquement, car `applies-to: version-updates` est utilisé. ```yaml version: 2 updates: # Keep bundler dependencies up to date - package-ecosystem: "bundler" directories: - "/frontend" - "/backend" - "/admin" schedule: interval: "weekly" # Create a group of dependencies to be updated together in one pull request groups: # Specify a name for the group, which will be used in pull request titles # and branch names support-dependencies: # Define patterns to include dependencies in the group (based on # dependency name) applies-to: version-updates # Applies the group rule to version updates patterns: - "rubocop" # A single dependency name - "rspec*" # A wildcard string that matches multiple dependency names - "*" # A wildcard that matches all dependencies in the package # ecosystem. Note: using "*" may open a large pull request # Define patterns to exclude dependencies from the group (based on # dependency name) exclude-patterns: - "gc_ruboconfig" - "gocardless-*" ``` Par conséquent : * La majorité des dépendances pour bundler sont consolidées dans le groupe `support-dependencies` en raison du modèle générique (« \* »), à part * Les dépendances qui correspondent `gc_ruboconfig` et `gocardless-*` sont exclues du groupe, et Dependabot continuent de déclencher des demandes de tirage uniques pour ces dépendances. Cela peut être utile si les mises à jour de ces dépendances doivent être examinées de manière plus approfondie. * Pour `support-dependencies`, Dependabot ne créera que des demandes de tirage pour les mises à jour de version. ### Exemple 3 : Demandes de tirage individuelles pour les mises à jour majeures et regroupées pour les mises à jour mineures/correctives Dans cet exemple, le`dependabot.yml` fichier : * Créez un groupe appelé  « `angular` ». * Utilisez `patterns` qui correspond au nom d’une dépendance pour inclure des dépendances dans le groupe. * Utilisez `update-type` pour inclure uniquement des mises à jour `minor` ou `patch` dans le groupe. * Appliquez le regroupement aux mises à jour de version uniquement, car `applies-to: version-updates` est utilisé. ```yaml version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" groups: # Specify a name for the group, which will be used in pull request titles # and branch names angular: applies-to: version-updates patterns: - "@angular*" update-types: - "minor" - "patch" ``` Par conséquent : * Dependabot crée une demande de tirage groupée pour toutes les dépendances Angular qui ont une mise à jour mineure ou corrective. * Toutes les mises à jour majeures continueront d’être déclenchées en tant que demandes de tirage individuelles. ### Exemple 4 : Demandes de tirage regroupées pour les mises à jour mineures/correctives et aucune demande de tirage pour les mises à jour majeures Dans cet exemple, le`dependabot.yml` fichier : * Créez trois groupes, appelés «`angular`» et «`minor-and-patch`». * Utilisez `applies-to` afin que le premier groupe s’applique uniquement aux mises à jour de version, et le deuxième groupe s’applique uniquement aux mises à jour de sécurité. * Utilisez `update-type` pour inclure uniquement des mises à jour `minor` ou `patch` pour les deux groupes. * Utilisez une `ignore` condition pour exclure les mises à jour de `major` version des `@angular*` packages . ```yaml version: 2 updates: # Keep npm dependencies up to date - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly" groups: angular: applies-to: version-updates patterns: - "@angular*" update-types: - "minor" - "patch" minor-and-patch: applies-to: security-updates patterns: - "@angular*" update-types: - "patch" - "minor" ignore: - dependency-name: "@angular*" update-types: ["version-update:semver-major"] ``` Par conséquent : * Les mises à jour mineures et correctives des versions pour les dépendances Angular sont regroupées en une seule demande de tirage. * Les mises à jour de sécurité mineures et correctives pour les dépendances Angular sont également regroupées en une seule demande de tirage. * Dependabot n’ouvre pas automatiquement les demandes de tirage pour les mises à jour majeures pour Angular. ### Regroupement des mises à jour entre les répertoires d’un monorepo Si vous gérez un monorepo avec plusieurs répertoires qui partagent des dépendances communes, vous pouvez réduire le nombre de demandes de tirage (pull request) pour les mises à jour de version en regroupant les mises à jour par nom de dépendance dans tous les répertoires. Lorsque vous configurez Dependabot pour surveiller plusieurs répertoires et activer le regroupement par nom de dépendance, Dependabot effectue les actions suivantes : * Créer une seule pull request pour chaque mise à jour de dépendance qui affecte plusieurs répertoires * Mettre à jour la même dépendance vers la même version dans tous les répertoires en une seule opération * Réduisez le nombre de pull requests que vous devez examiner * Réduire les coûts CI/CD en exécutant des tests une seule fois plutôt qu'individuellement pour chaque répertoire. Pour plus d’informations, consultez [`group-by`](/fr/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups). Cet exemple de configuration regroupe les mises à jour par nom de dépendance dans les répertoires `/frontend`, `/admin-panel` et `/mobile-app`. Si `lodash` doit être mis à jour dans les trois répertoires, Dependabot créera une pull request unique nommée « Bump lodash in monorepo-dependencies group » qui mettra à jour `lodash` dans les trois emplacements. ```yaml version: 2 updates: - package-ecosystem: "npm" directories: - "/frontend" - "/admin-panel" - "/mobile-app" schedule: interval: "weekly" groups: monorepo-dependencies: group-by: dependency-name ```