{"meta":{"title":"Optimisation de la création de requêtes de tirage pour les mises à jour de version Dependabot","intro":"Découvrez comment rationaliser et gérer efficacement vos Dependabot pull requests.","product":"Sécurité et qualité du code","breadcrumbs":[{"href":"/fr/code-security","title":"Sécurité et qualité du code"},{"href":"/fr/code-security/tutorials","title":"Tutorials"},{"href":"/fr/code-security/tutorials/secure-your-dependencies","title":"Sécurisez vos dépendances"},{"href":"/fr/code-security/tutorials/secure-your-dependencies/optimizing-pr-creation-version-updates","title":"Optimiser la création de PR"}],"documentType":"article"},"body":"# Optimisation de la création de requêtes de tirage pour les mises à jour de version Dependabot\n\nDécouvrez comment rationaliser et gérer efficacement vos Dependabot pull requests.\n\nPar 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`.\n\nSi 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.\n\nIl 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 :\n\\*\n**Contrôle de la fréquence** avec laquelle Dependabot vérifie les versions plus récentes de vos dépendances avec `schedule`.\n\\*\n**Priorité aux mises à jour significatives** avec `groups`.\n\n## Contrôle de la fréquence et du moment des mises à jour des dépendances\n\n```\n          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)).\n```\n\nPar 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.\n\nToutefois, 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.\n\n### Modification de la fréquence et des délais pour les mises à jour des dépendances\n\nVous 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.\n\nL’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).\n\n```yaml copy\n# `dependabot.yml` file with\n# customized schedule for version updates\n\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    # Check the npm registry every week on Tuesday at 02:00 Japan Standard Time (UTC +09:00)\n    schedule:\n      interval: \"weekly\"\n      day: \"tuesday\"\n      time: \"02:00\"\n      timezone: \"Asia/Tokyo\"\n```\n\nConsultez également [planification](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#schedule-).\n\n### Configuration d’une période d’attente pour les mises à jour des dépendances\n\nVous 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é**.\n\nLe 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**.\n\n```yaml copy\nversion: 2\nupdates:\n  - package-ecosystem: \"pip\"\n    directory: \"/\"\n    schedule:\n      interval: \"daily\"\n    cooldown:\n      default-days: 5\n      semver-major-days: 30\n      semver-minor-days: 7\n      semver-patch-days: 3\n      include:\n        - \"requests\"\n        - \"numpy\"\n        - \"pandas*\"\n        - \"django\"\n      exclude:\n        - \"pandas\"\n```\n\n* Le nombre de jours de délai doit être compris entre 1 et 90.\n* 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.\n\n> \\[!NOTE]\n> Pour prendre en compte **toutes les dépendances** pour une période de refroidissement, vous pouvez :\n>\n> * Omettez l’option `include` qui applique un délai d’attente à toutes les dépendances.\n> * Utilisez `\"*\"` dans `include` pour appliquer les paramètres de délai d’attente à l’ensemble des éléments.\n>   Nous vous recommandons d’utiliser `exclude` pour **uniquement** exclure des **dépendances spécifiques** des paramètres de refroidissement.\n\nSemVer 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 :\n\n* Mises à jour majeures : retardées de 30 jours (`semver-major-days: 30`).\n* Mises à jour mineures : retardées de 7 jours (`semver-minor-days: 7`).\n* Mises à jour correctives : retardées de 3 jours (`semver-patch-days: 3`).\n\nVoir aussi [`cooldown`](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown-).\n\n## Priorité aux mises à jour significatives\n\n### Regroupement des dépendances associées\n\nVous 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.\n\nIl 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 :\n\n* ```\n          Dependabot type de mise à jour : `applies-to`\n  ```\n* Type de dépendance : `dependency-type`.\n* Nom de dépendance : `patterns` et `exclude-patterns`\n* Niveaux de version sémantique : `update-types`\n\nPour afficher toutes les valeurs prises en charge pour chaque critère, consultez [`groups`](/fr/code-security/dependabot/working-with-dependabot/dependabot-options-reference#groups--).\n\nLes exemples ci-dessous présentent plusieurs méthodes différentes pour créer des groupes de dépendances à l’aide des critères.\n\n### Exemple 1 : Trois groupes de mise à jour des versions\n\nDans cet exemple, le`dependabot.yml` fichier :\n\n* Créez trois groupes, appelés «`production-dependencies`», «`development-dependencies`» et «`rubocop`».\n* Utilisez `patterns` et `dependency-type` pour inclure des dépendances dans le groupe.\n* Utilisez `exclude-patterns` pour exclure une dépendance (ou plusieurs dépendances) du groupe.\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      production-dependencies:\n        dependency-type: \"production\"\n      development-dependencies:\n        dependency-type: \"development\"\n        exclude-patterns:\n          - \"rubocop*\"\n      rubocop:\n        patterns:\n          - \"rubocop*\"\n```\n\nPar conséquent :\n\n* Les mises à jour de version sont regroupées par type de dépendance.\n* Les dépendances de développement correspondant au modèle `rubocop*` sont exclues du groupe `development-dependencies` .\n* 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`.\n* Qui plus est, tous les groupes s’appliquent par défaut aux mises à jour de version uniquement, car la clé `applies-to` est absente.\n\n### Exemple 2 : Mises à jour groupées avec dépendances exclues\n\nDans cet exemple, le`dependabot.yml` fichier :\n\n* Créez un groupe appelé « `support-dependencies` », dans le cadre d’une configuration Bundler personnalisée.\n* Utilisez `patterns` qui correspond au nom d’une dépendance (ou plusieurs dépendances) pour inclure des dépendances dans le groupe.\n* Utilisez `exclude-patterns` qui correspond au nom d’une dépendance (ou plusieurs dépendances) pour exclure les dépendances du groupe.\n* Appliquez le regroupement aux mises à jour de version uniquement, car `applies-to: version-updates` est utilisé.\n\n```yaml\nversion: 2\nupdates:\n  # Keep bundler dependencies up to date\n  - package-ecosystem: \"bundler\"\n    directories:\n      - \"/frontend\"\n      - \"/backend\"\n      - \"/admin\"\n\n    schedule:\n      interval: \"weekly\"\n    # Create a group of dependencies to be updated together in one pull request\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      support-dependencies:\n        # Define patterns to include dependencies in the group (based on\n        # dependency name)\n        applies-to: version-updates # Applies the group rule to version updates\n        patterns:\n          - \"rubocop\" # A single dependency name\n          - \"rspec*\"  # A wildcard string that matches multiple dependency names\n          - \"*\"       # A wildcard that matches all dependencies in the package\n                      # ecosystem. Note: using \"*\" may open a large pull request\n        # Define patterns to exclude dependencies from the group (based on\n        # dependency name)\n        exclude-patterns:\n          - \"gc_ruboconfig\"\n          - \"gocardless-*\"\n```\n\nPar conséquent :\n\n* La majorité des dépendances pour bundler sont consolidées dans le groupe `support-dependencies` en raison du modèle générique (« \\* »), à part\n* 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.\n* Pour `support-dependencies`, Dependabot ne créera que des demandes de tirage pour les mises à jour de version.\n\n### Exemple 3 : Demandes de tirage individuelles pour les mises à jour majeures et regroupées pour les mises à jour mineures/correctives\n\nDans cet exemple, le`dependabot.yml` fichier :\n\n* Créez un groupe appelé  « `angular` ».\n* Utilisez `patterns` qui correspond au nom d’une dépendance pour inclure des dépendances dans le groupe.\n* Utilisez `update-type` pour inclure uniquement des mises à jour `minor` ou `patch` dans le groupe.\n* Appliquez le regroupement aux mises à jour de version uniquement, car `applies-to: version-updates` est utilisé.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      # Specify a name for the group, which will be used in pull request titles\n      # and branch names\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n```\n\nPar conséquent :\n\n* Dependabot crée une demande de tirage groupée pour toutes les dépendances Angular qui ont une mise à jour mineure ou corrective.\n* Toutes les mises à jour majeures continueront d’être déclenchées en tant que demandes de tirage individuelles.\n\n### Exemple 4 : Demandes de tirage regroupées pour les mises à jour mineures/correctives et aucune demande de tirage pour les mises à jour majeures\n\nDans cet exemple, le`dependabot.yml` fichier :\n\n* Créez trois groupes, appelés «`angular`» et «`minor-and-patch`».\n* 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é.\n* Utilisez `update-type` pour inclure uniquement des mises à jour `minor` ou `patch` pour les deux groupes.\n* Utilisez une `ignore` condition pour exclure les mises à jour de `major` version des `@angular*` packages .\n\n```yaml\nversion: 2\nupdates:\n  # Keep npm dependencies up to date\n  - package-ecosystem: \"npm\"\n    directory: \"/\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      angular:\n        applies-to: version-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"minor\"\n          - \"patch\"\n      minor-and-patch:\n        applies-to: security-updates\n        patterns:\n          - \"@angular*\"\n        update-types:\n          - \"patch\"\n          - \"minor\"\n    ignore:\n      - dependency-name: \"@angular*\"\n        update-types: [\"version-update:semver-major\"]\n```\n\nPar conséquent :\n\n* Les mises à jour mineures et correctives des versions pour les dépendances Angular sont regroupées en une seule demande de tirage.\n* Les mises à jour de sécurité mineures et correctives pour les dépendances Angular sont également regroupées en une seule demande de tirage.\n* Dependabot n’ouvre pas automatiquement les demandes de tirage pour les mises à jour majeures pour Angular.\n\n### Regroupement des mises à jour entre les répertoires d’un monorepo\n\nSi 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.\n\nLorsque vous configurez Dependabot pour surveiller plusieurs répertoires et activer le regroupement par nom de dépendance, Dependabot effectue les actions suivantes :\n\n* Créer une seule pull request pour chaque mise à jour de dépendance qui affecte plusieurs répertoires\n* Mettre à jour la même dépendance vers la même version dans tous les répertoires en une seule opération\n* Réduisez le nombre de pull requests que vous devez examiner\n* Réduire les coûts CI/CD en exécutant des tests une seule fois plutôt qu'individuellement pour chaque répertoire.\n\nPour plus d’informations, consultez [`group-by`](/fr/code-security/reference/supply-chain-security/dependabot-options-reference#group-by-groups).\n\nCet 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.\n\n```yaml\nversion: 2\nupdates:\n  - package-ecosystem: \"npm\"\n    directories:\n      - \"/frontend\"\n      - \"/admin-panel\"\n      - \"/mobile-app\"\n    schedule:\n      interval: \"weekly\"\n    groups:\n      monorepo-dependencies:\n        group-by: dependency-name\n```"}