steps:
- name: Checkout code
  uses: actions/checkout@v6.0.2

steps:
- name: Checkout code
  uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Ajout du fichier .github/dependabot.yml

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

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

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

Configuration complète (couvre les workflows, le Dockerfile et les dépendances Java)

Le contenu du fichier dépend uniquement de ce que l'on veut surveiller
     Il suffit d'ajouter, par exemple; - package-ecosystem: "github-actions",
     de lui donner le chemin d'accès, et l'interval à suivre pour qu'il s'occuppe de tout, où presque

Centralisation: Dependabot n'utilise qu'un seule fichier
     Il scanne tous les fichiers yaml, situés dans le dossier .github/workflows/

Automatisation des SHA: Dependabot détecte si une nouvelle version existe,
     Il crée ensuite une PR (de plusieurs fichiers parfois) en mettant à jour le(s) SHA,
     Il ajoute un commentaire avec le(s) numéro(s) de version

Stabilité: On recoit les mises à jour sur une branche séparée.
     On peut ainsi tester les mises à jourt AVANT de les merger dans les différentes branches

Le fichier "Dockerfile"

Utiliser un SHA pour l'image de base, c'est comme pour les Actions;
On utilise un SHA pour le FROM afin d'être 100% reproductible

Dans ce cas, il va surveiller la ligne "FROM gcr.io/distroless/java17-debian12" et proposer une "Pull Request" dès qu'une nouvelle image de base, plus sécurisée, sera publiée par Google

→ Une fois que l'on obtiens le SHA, modifiez le Dockerfile ainsi:
FROM gcr.io/distroless/java17-debian12@sha256:le_sha_ici

Tester avant de procéder au changement

docker pull gcr.io/distroless/java17-debian12

docker inspect --format='{{index .RepoDigests 0}}' \
	gcr.io/distroless/java17-debian12

Pour Java, c'est encore plus puissant:
Dependabot analyse le fichier pom.xml. Si on mets à jour une dépendance, il vérifie les versions disponibles sur Maven Central. Il regroupe les mises à jour si on utilise l'option groups, ce qui évite d'avoir 50 PRs ouvertes

Le regroupement réduit le "bruit" des Pull Requests en fusionnant plusieurs mises à jour liées, en une seule PR

Configuration des secrets

settings → secrets/dependabot

Tableaux de bords des mise à jour

• Dependencies: Contient une liste de dépendance, On peut filtrer par eco-system (Maven, Github Actions), on peux aussi activer la soumission automatique afin de recevoir des alertes Dependabot pour les vulnérabilités connues
• Dependents:
• Dependabot: Affiche les récentes mise à jour et les fichiers modifiés

Tableaux de bords des alertes

Vulnerability Alert
       Dependabot 1

Cibler la branche

Pour ma stratégie Git, les alertes de mise à jour sont envoyés sur la branche [develop], idéal pour suivre le cycle normal des PR/merges

version: 2
updates:
  - package-ecosystem: "github-actions"
    target-branch: develop
    directory: "/"
    schedule:
      interval: "weekly"

    groups:
      github-actions:
        patterns:
          - "*"

Déroulé du PR: CI FAILED

Contexte:
Le build est rouge et on a fermé le PR, on reçoit alors un message avec des instructions: →

groups:
  major-and-patch:
    update-types: ["patch", "major"]

Une CI verte enclenche le processus de merge habituel