Tools
Dependabot zähmen - Updates gruppieren, Rhythmus drosseln, Sicherheit schnell halten
Montagmorgens, du öffnest deine Notifications - und da sind sie: fünf, zehn, manchmal ein Dutzend Dependabot Pull Requests, jeder für eine einzelne Abhängigkeit. Individuell hilfreich, kollektiv Lärm. Und Lärm ist, wie wichtige Updates ignoriert werden.
Ein Blick auf Microsofts GCToolkit-Repo zeigte: 92 von 578 Commits waren Dependabot-Bumps. Das ist jeder sechste Commit. Das muss nicht so sein.
Die Lösung: Drei Änderungen
1. Alles in einen Pull Request gruppieren
Ein groups-Block mit Wildcard-Pattern (patterns: ["*"]) bündelt alle Updates pro Ökosystem in einem einzigen PR. Statt 10 Pull Requests bekommst du einen Titel wie “Bump the monthly-batch group with 10 updates”. Ein Branch, ein CI-Lauf, eine Review.
2. Kadenz von daily auf monthly
schedule.interval: "monthly" ändert den Rhythmus von “immer wenn sich etwas ändert” zu “einmal pro Monat, planbar”. Kombiniert mit Gruppierung ist das die echte Lärmreduktion: ein gebündelter PR pro Ökosystem pro Monat.
3. Alle Ökosysteme abdecken
Viele Configs uberwachen nur github-actions, vergessen aber maven, npm, pip etc. Jedes Ökosystem bekommt seinen eigenen Schedule und seine eigene Gruppe.
Sicherheit bleibt sofort
Der Schlüssel: Gruppen und Schedule betreffen nur Version-Updates, nicht Security-Fixes. Dependabot Security Updates werden weiterhin sofort bei Bekanntwerden einer Schwachstelle ausgelöst, unabhängig vom Schedule. Monatliche Routine-Bumps verzögern also keinen kritischen Patch.
Zusätzlich gibt es seit kurzem einen Default-Cooldown: Dependabot wartet drei Tage, bevor ein Version-Update-PR eröffnet wird - als Schutz vor Supply-Chain-Angriffen über frisch veröffentlichte Releases.
Praxis-Tipps
- Starte breit mit einem Wildcard-Gruppe, splitte später bei Bedarf
- Nutze
directoriesmit Globs für Monorepos (/apps/*) group-by: dependency-namefasst gleiche Libraries über mehrere Verzeichnisse zusammen- Cooldown-Länge ist konfigurierbar (
cooldown.default-days: 7)
Mit etwa einem Dutzend Zeilen YAML wird aus einem Daily-PR-Strom ein sauberer monatlicher Batch. Weniger PRs, weniger CI-Läufe, und die Updates, die wirklich zählen, gehen nicht im Rauschen unter.
Quelle: GitHub Blog