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.

Qui peut utiliser cette fonctionnalité ?

Users with write access

Dans cet article

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
# `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.

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
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.

Remarque

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.

Priorité aux mises à jour significatives

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.

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, ledependabot.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.
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 productionrubocop* 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, ledependabot.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é.
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, ledependabot.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é.
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, ledependabot.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 .
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.

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.

version: 2
updates:
  - package-ecosystem: "npm"
    directories:
      - "/frontend"
      - "/admin-panel"
      - "/mobile-app"
    schedule:
      interval: "weekly"
    groups:
      monorepo-dependencies:
        group-by: dependency-name