dependabot

Par github · awesome-copilot

Guide complet pour configurer et gérer GitHub Dependabot. Utilisez cette skill lorsque les utilisateurs posent des questions sur la création ou l'optimisation de fichiers `dependabot.yml`, la gestion des pull requests Dependabot, la configuration des stratégies de mise à jour des dépendances, la mise en place de mises à jour groupées, les patterns monorepo, les groupes multi-écosystèmes, la configuration des mises à jour de sécurité, les règles d'auto-triage, ou tout autre sujet de sécurité de la chaîne d'approvisionnement lié à Dependabot dans le cadre de GitHub Advanced Security (GHAS).

npx skills add https://github.com/github/awesome-copilot --skill dependabot

Configuration et gestion de Dependabot

Aperçu

Dependabot est l'outil de gestion des dépendances intégré de GitHub avec trois capacités principales :

  1. Dependabot Alerts — Notifier quand les dépendances ont des vulnérabilités connues (CVE)
  2. Dependabot Security Updates — Créer automatiquement des PRs pour corriger les dépendances vulnérables
  3. Dependabot Version Updates — Créer automatiquement des PRs pour maintenir les dépendances à jour

Toute la configuration se trouve dans un seul fichier : .github/dependabot.yml sur la branche par défaut. GitHub ne supporte pas plusieurs fichiers dependabot.yml par repository.

Flux de travail de configuration

Suivez ce processus lors de la création ou l'optimisation d'un dependabot.yml :

Étape 1 : Détecter tous les écosystèmes

Scannez le repository pour les manifests de dépendances. Cherchez :

Écosystème Valeur YAML Fichiers manifest
npm/pnpm/yarn npm package.json, package-lock.json, pnpm-lock.yaml, yarn.lock
pip/pipenv/poetry/uv pip requirements.txt, Pipfile, pyproject.toml, setup.py
Docker docker Dockerfile
Docker Compose docker-compose docker-compose.yml
GitHub Actions github-actions .github/workflows/*.yml
Go modules gomod go.mod
Bundler (Ruby) bundler Gemfile
Cargo (Rust) cargo Cargo.toml
Composer (PHP) composer composer.json
NuGet (.NET) nuget *.csproj, packages.config
.NET SDK dotnet-sdk global.json
Maven (Java) maven pom.xml
Gradle (Java) gradle build.gradle
Terraform terraform *.tf
OpenTofu opentofu *.tf
Helm helm Chart.yaml
Hex (Elixir) mix mix.exs
Swift swift Package.swift
Pub (Dart) pub pubspec.yaml
Bun bun bun.lockb
Dev Containers devcontainers devcontainer.json
Git Submodules gitsubmodule .gitmodules
Pre-commit pre-commit .pre-commit-config.yaml

Note : pnpm et yarn utilisent tous les deux la valeur d'écosystème npm.

Étape 2 : Mapper les emplacements des répertoires

Pour chaque écosystème, identifiez où se trouvent les manifests. Utilisez directories (pluriel) avec des patterns glob pour les monorepos :

directories:
  - "/"           # racine
  - "/apps/*"     # tous les répertoires app
  - "/packages/*" # tous les répertoires package
  - "/lib-*"      # répertoires commençant par lib-
  - "**/*"        # récursif (tous les répertoires)

Important : directory (singulier) ne supporte PAS les globs. Utilisez directories (pluriel) pour les caractères génériques.

Étape 3 : Configurer chaque entrée d'écosystème

Chaque entrée a besoin au minimum de :

- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"

Étape 4 : Optimiser avec groupement, labels et planification

Voir les sections ci-dessous pour chaque technique d'optimisation.

Stratégies pour monorepos

Patterns Glob pour couverture d'espace de travail

Pour les monorepos avec beaucoup de packages, utilisez des patterns glob pour éviter de lister chaque répertoire :

- package-ecosystem: "npm"
  directories:
    - "/"
    - "/apps/*"
    - "/packages/*"
    - "/services/*"
  schedule:
    interval: "weekly"

Groupement cross-répertoire

Utilisez group-by: dependency-name pour créer une seule PR quand la même dépendance se met à jour sur plusieurs répertoires :

groups:
  monorepo-deps:
    group-by: dependency-name

Cela crée une PR par dépendance sur tous les répertoires spécifiés, réduisant les coûts CI et la charge de review.

Limitations :

  • Tous les répertoires doivent utiliser le même écosystème de package
  • S'applique uniquement aux mises à jour de version
  • Les contraintes de version incompatibles créent des PRs séparées

Packages autonomes en dehors des espaces de travail

Si un répertoire a son propre lockfile et ne fait PAS partie de l'espace de travail (p. ex., scripts dans .github/), créez une entrée d'écosystème séparée pour celui-ci.

Groupement des dépendances

Réduisez le bruit des PRs en groupant les dépendances liées dans des PRs uniques.

Par type de dépendance

groups:
  dev-dependencies:
    dependency-type: "development"
    update-types: ["minor", "patch"]
  production-dependencies:
    dependency-type: "production"
    update-types: ["minor", "patch"]

Par pattern de nom

groups:
  angular:
    patterns: ["@angular*"]
    update-types: ["minor", "patch"]
  testing:
    patterns: ["jest*", "@testing-library*", "ts-jest"]

Pour les mises à jour de sécurité

groups:
  security-patches:
    applies-to: security-updates
    patterns: ["*"]
    update-types: ["patch", "minor"]

Comportements clés :

  • Les dépendances correspondant à plusieurs groupes vont au premier match
  • applies-to par défaut à version-updates quand absent
  • Les dépendances non groupées obtiennent des PRs individuelles

Groupes multi-écosystèmes

Combinez les mises à jour sur différents écosystèmes de package dans une seule PR :

version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"
    labels: ["infrastructure", "dependencies"]

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws*"]
    multi-ecosystem-group: "infrastructure"

La clé patterns est requise quand on utilise multi-ecosystem-group.

Personnalisation des PRs

Labels

labels:
  - "dependencies"
  - "npm"

Définissez labels: [] pour désactiver tous les labels y compris les défauts. Les labels SemVer (major, minor, patch) sont toujours appliqués s'ils sont présents dans le repo.

Messages de commit

commit-message:
  prefix: "deps"
  prefix-development: "deps-dev"
  include: "scope"  # ajoute deps/deps-dev scope après le préfixe

Assignés et jalons

assignees: ["security-team-lead"]
milestone: 4  # ID numérique depuis l'URL du jalon

Séparateur de nom de branche

pull-request-branch-name:
  separator: "-"  # par défaut est /

Branche cible

target-branch: "develop"  # les PRs ciblent ceci au lieu de la branche par défaut

Note : Quand target-branch est défini, les mises à jour de sécurité ciblent toujours la branche par défaut ; toute la configuration d'écosystème s'applique uniquement aux mises à jour de version.

Optimisation de la planification

Intervalles

Supportés : daily, weekly, monthly, quarterly, semiannually, yearly, cron

schedule:
  interval: "weekly"
  day: "monday"         # pour weekly uniquement
  time: "09:00"         # format HH:MM
  timezone: "America/New_York"

Expressions Cron

schedule:
  interval: "cron"
  cronjob: "0 9 * * 1"  # Chaque lundi à 9 AM

Périodes de refroidissement

Retardez les mises à jour pour les versions récemment publiées pour éviter les problèmes des early adopters :

cooldown:
  default-days: 5
  semver-major-days: 30
  semver-minor-days: 7
  semver-patch-days: 3
  include: ["*"]
  exclude: ["critical-lib"]

Le cooldown s'applique uniquement aux mises à jour de version, pas aux mises à jour de sécurité.

Configuration des mises à jour de sécurité

Activer via les paramètres du repository

Settings → Advanced Security → Enable Dependabot alerts, security updates, and grouped security updates.

Grouper les mises à jour de sécurité en YAML

groups:
  security-patches:
    applies-to: security-updates
    patterns: ["*"]
    update-types: ["patch", "minor"]

Désactiver les mises à jour de version (sécurité uniquement)

open-pull-requests-limit: 0  # désactive les PRs de mise à jour de version

Règles de tri automatique

GitHub prérégle le rejet automatique des alertes à faible impact pour les dépendances de développement. Les règles personnalisées peuvent filtrer par sévérité, nom de package, CWE, et plus. Configurez dans Settings → Advanced Security du repository.

Commandes de commentaires PR

Interagissez avec les PRs Dependabot en utilisant les commentaires @dependabot.

Note : Depuis janvier 2026, les commandes merge/close/reopen ont été dépréciées. Utilisez l'interface native de GitHub, la CLI (gh pr merge), ou l'auto-merge à la place.

Commande Effet
@dependabot rebase Rebase la PR
@dependabot recreate Recréer la PR de zéro
@dependabot ignore this dependency Fermer et ne jamais mettre à jour cette dépendance
@dependabot ignore this major version Ignorer cette version majeure
@dependabot ignore this minor version Ignorer cette version mineure
@dependabot ignore this patch version Ignorer cette version patch

Pour les PRs groupées, commandes supplémentaires :

  • @dependabot ignore DEPENDENCY_NAME — ignorer une dépendance spécifique dans le groupe
  • @dependabot unignore DEPENDENCY_NAME — effacer les ignores, rouvrir avec mises à jour
  • @dependabot unignore * — effacer tous les ignores pour toutes les dépendances du groupe
  • @dependabot show DEPENDENCY_NAME ignore conditions — afficher les ignores courants

Pour la référence complète des commandes, consultez references/pr-commands.md.

Règles d'ignorage et d'autorisation

Ignorer des dépendances spécifiques

ignore:
  - dependency-name: "lodash"
  - dependency-name: "@types/node"
    update-types: ["version-update:semver-patch"]
  - dependency-name: "express"
    versions: ["5.x"]

Autoriser uniquement des types spécifiques

allow:
  - dependency-type: "production"
  - dependency-name: "express"

Règle : Si une dépendance correspond à la fois à allow et ignore, elle est ignorée.

Exclure des chemins

exclude-paths:
  - "vendor/**"
  - "test/fixtures/**"

Options avancées

Stratégie de versioning

Contrôle comment Dependabot modifie les contraintes de version :

Valeur Comportement
auto Par défaut — augmenter pour les apps, élargir pour les bibliothèques
increase Toujours augmenter la version minimale
increase-if-necessary Changer uniquement si la plage actuelle exclut la nouvelle version
lockfile-only Mettre à jour uniquement les lockfiles, ignorer les manifests
widen Élargir la plage pour inclure les anciennes et nouvelles versions

Stratégie de rebase

rebase-strategy: "disabled"  # arrêter le rebase automatique

Autoriser le rebase sur des commits supplémentaires en incluant [dependabot skip] dans les messages de commit.

Limite de PR ouvertes

open-pull-requests-limit: 10  # par défaut 5 pour version, 10 pour sécurité

Définissez à 0 pour désactiver complètement les mises à jour de version.

Registries privés

registries:
  npm-private:
    type: npm-registry
    url: https://npm.example.com
    token: ${{secrets.NPM_TOKEN}}

updates:
  - package-ecosystem: "npm"
    directory: "/"
    registries:
      - npm-private

FAQ

Puis-je avoir plusieurs fichiers dependabot.yml ? Non. GitHub supporte exactement un fichier à .github/dependabot.yml. Utilisez plusieurs entrées updates dans ce fichier pour différents écosystèmes et répertoires.

Dependabot supporte-t-il pnpm ? Oui. Utilisez package-ecosystem: "npm" — Dependabot détecte pnpm-lock.yaml automatiquement.

Comment je réduis le bruit des PRs dans un monorepo ? Utilisez groups pour les mises à jour batch, directories avec globs pour la couverture, et group-by: dependency-name pour le groupement cross-répertoire. Considérez des intervalles monthly ou quarterly pour les écosystèmes de basse priorité.

Comment je gère les dépendances en dehors de l'espace de travail ? Créez une entrée d'écosystème séparée avec son propre directory pointant à cet emplacement.

Ressources

  • references/dependabot-yml-reference.md — Référence complète des options YAML
  • references/pr-commands.md — Référence complète des commandes de commentaires PR
  • references/example-configs.md — Exemples de configuration du monde réel

Skills similaires