Renovate im Betrieb: die Stolpersteine im Detail

Diese Sammlung ist als Nachschlagewerk gedacht, nicht als Lektüre von vorn nach hinten. Sie richtet sich an alle, die Renovate bereits betreiben und ein konkretes Verhalten einordnen müssen: einen Bot, der nichts tut, einen Zeitplan, der nicht greift, ein Automerge, das ausbleibt, oder ein Upgrade, nach dem plötzlich mehr Pull Requests entstehen als vorher.

Wenn Sie Renovate erst aufsetzen, arbeiten Sie zuerst den Hauptbeitrag Updates, die sich selbst vorschlagen: Abhängigkeiten mit Renovate durch. Er enthält die Schritte mit den zugehörigen Prüfbefehlen. Die drei folgenreichsten Fälle stehen dort ebenfalls, in dieser Sammlung finden Sie sie der Vollständigkeit halber noch einmal.

Die Fälle 1 bis 4 betreffen den Einstieg, die Fälle 5 bis 12 den laufenden Betrieb, die Fälle 13 bis 19 Plattformbesonderheiten und Versionswechsel.

Einstieg und erste Läufe

1. Renovate legt keine Update-PRs an

Symptom: Der Bot läuft ohne Fehler, es liegt aber nur ein offener Pull Request „Configure Renovate“ vor.

Ursache: Renovate ändert bis zum Merge des Onboarding-PR nichts weiter am Repository. Das ist Absicht.

Prüfung:

git fetch origin && git log origin/main --oneline -- renovate.json

Der Merge-Commit der Onboarding-Datei muss auf dem Default-Branch liegen.

Lösung: Onboarding-PR prüfen und mergen. Anpassungen können Sie vorher direkt im Branch renovate/configure vornehmen, Renovate aktualisiert die PR-Beschreibung dann laufend. Wer kein Onboarding will, schließt den PR und committet die Konfiguration von Hand.

2. Lockfile-Aktualisierung schlägt fehl

Symptom: Renovate wurde per npm installiert, das Anheben der Version klappt, die Lockfile-Aktualisierung bricht ab.

Ursache: Renovate bringt npm, pnpm und yarn nicht mit. Es kann Lockfiles nicht rückwärts interpretieren, sondern patcht die Package-Datei und überlässt den Rest dem Paketmanager. Fehlt der, schlägt der Schritt fehl.

Prüfung:

renovate --version && yarn --version && pnpm --version

Lösung: Benötigte Paketmanager global installieren, etwa npm install -g yarn pnpm. Alternativ das -full-Image nutzen. Es bringt laut Dokumentation die meisten, aber nicht alle unterstützten Paketmanager mit, davon je eine Version, und wiegt mehrere Gigabyte.

3. ArgoCD-Applications werden ignoriert

Symptom: Die ArgoCD-Manifeste liegen im Repository, Renovate erkennt sie aber nicht.

Ursache: Der argocd-Manager matcht per Default keine einzige Datei, weil sich ArgoCD-Dateinamen nicht automatisch bestimmen lassen. Der Manager existiert, greift aber ohne managerFilePatterns ins Leere.

Prüfung:

LOG_LEVEL=debug npx --yes --package renovate -- renovate --dry-run=extract meine-gruppe/mein-repo

Im Debug-Log muss der Manager argocd mit den gefundenen Dateien auftauchen.

Lösung: managerFilePatterns explizit setzen, etwa {"argocd": {"managerFilePatterns": ["/argocd/.+\\.yaml$/"]}}. Der Manager extrahiert dann aus den Datasources docker, git-tags und helm.

4. Nach enabledManagers verschwinden Updates

Symptom: Nach dem Setzen von enabledManagers kommen plötzlich keine Updates mehr für Docker-Compose, Bundler oder Composer.

Ursache: enabledManagers wirkt exklusiv. Alles, was nicht in der Liste steht, ist deaktiviert. Die Dokumentation weist ausdrücklich darauf hin.

Prüfung:

npx --yes --package renovate -- renovate --dry-run=extract meine-gruppe/mein-repo

Die Zahl der extrahierten Manager gegen die Erwartung abgleichen.

Lösung: Statt enabledManagers gezielt einzelne Manager abschalten, etwa {"gradle": {"enabled": false}}. Wer enabledManagers braucht, muss jeden benötigten Manager namentlich aufführen.

Laufender Betrieb

5. Der Schedule wird nicht angenommen

Symptom: Ein Zeitplan wie „jeden Montag um 03:15“ verhält sich unerwartet oder greift gar nicht.

Ursache: Renovate unterstützt keine Minutengranularität. Der Cron-Ausdruck muss fünf Teile haben, die Auflösung beträgt mindestens eine Stunde. Zusätzlich gilt per Default UTC, nicht die lokale Zeit.

Prüfung:

npx --yes --package renovate -- renovate-config-validator --strict

Muss mit Exit-Code 0 durchlaufen.

Lösung: Stundenfenster statt Zeitpunkte angeben, etwa "schedule": ["* 0-4,22-23 * * 1-5"], und die Zone explizit setzen mit "timezone": "Europe/Berlin".

6. Das Zeitfenster wird regelmäßig verpasst

Symptom: Das Fenster ist gesetzt, Renovate läuft trotzdem scheinbar nie.

Ursache: Die gehosteten Mend-Apps prüfen ein Repository nach einem festen Takt. Für Community Cloud nennt die Dokumentation alle vier Stunden für aktive Repositories. Ein zu schmales Fenster fällt zwischen zwei Läufe.

Prüfung: Unter Build > Pipeline schedules beziehungsweise in der Job-Historie der App kontrollieren, wann der letzte Lauf stattgefunden hat.

Lösung: Das Zeitfenster mindestens so breit wählen, dass ein Lauf im Takt der jeweiligen Plan-Stufe hineinfällt. Beim Self-Hosting per GitLab Renovate Runner einen stündlichen Pipeline-Schedule anlegen, im Doku-Beispiel 3 * * * *.

7. Automerge passiert nicht

Symptom: automerge ist konfiguriert, es wird trotzdem nichts gemergt.

Ursache: Renovate merged erst, wenn es grüne Status-Checks für den Branch sieht, und nur wenn der Branch mit dem Ziel-Branch aktuell ist. Ohne CI passiert nichts.

Prüfung: Am offenen Renovate-Pull-Request kontrollieren, ob alle Status-Checks grün sind und der Branch zum Ziel-Branch aktuell ist.

Lösung: CI einrichten, die auf Renovate-Branches läuft. Nur als Notlösung "ignoreTests": true setzen, wovon die Dokumentation zum Automerge ausdrücklich abrät.

8. Trotz Automerge bleiben viele PRs liegen

Symptom: Es gibt viele automergefähige Updates, die Zahl offener Pull Requests sinkt trotzdem kaum.

Ursache: Renovate merged pro Lauf höchstens einen Branch beziehungsweise Pull Request und startet den Repo-Lauf danach höchstens einmal neu. Ein aktiver Ziel-Branch verschärft das, weil Branches dann nicht mehr aktuell sind.

Prüfung: Über mehrere Läufe beobachten, ob die Zahl offener Renovate-Pull-Requests sinkt. Im Debug-Log die Automerge-Entscheidung pro Branch nachlesen.

Lösung: Laufintervall erhöhen und Updates über groupName zu wenigen kombinierten Pull Requests bündeln, damit weniger Merges nötig sind.

9. Die PR-Bremse greift, die CI läuft trotzdem dauernd

Symptom: prHourlyLimit ist gesetzt, die Zahl neuer Pull Requests bleibt im Rahmen, die CI-Auslastung sinkt aber nicht.

Ursache: prHourlyLimit begrenzt laut Dokumentation ausschließlich die Erstellung neuer Pull Requests. Renovate kann bestehende Branches weiter rebasen, und jeder dieser Pushes löst einen CI-Lauf aus.

Prüfung: In der CI-Historie zählen, wie viele Läufe auf renovate/-Branches entfallen, die zu bereits offenen Pull Requests gehören.

Lösung: commitHourlyLimit setzen. Die Dokumentation weist diese Option ausdrücklich als das Mittel aus, mit dem sich die Rate der von Renovate ausgelösten CI-Läufe strikt kontrollieren lässt, weil sie sowohl neue Branches als auch Rebases begrenzt. Der Default ist 0 und bedeutet kein Limit, die Option muss also aktiv gesetzt werden.

10. autodiscover greift zu weit

Symptom: Ein aktivierter autodiscover-Lauf fasst deutlich mehr Repositories an als beabsichtigt.

Ursache: autodiscover läuft per Default gegen jedes Repository, auf das der Bot-Account zugreifen kann.

Prüfung: Erst mit --dry-run=extract laufen lassen und im Log die Liste der erkannten Repositories gegen die Erwartung prüfen.

Lösung: autodiscoverFilter setzen. Das Muster wird gegen den Pfad organization/repo geprüft und akzeptiert Minimatch-Globs oder RE2-Regex.

11. Rate-Limit gegen github.com

Symptom: Self-gehostetes Renovate wird nach kurzer Zeit ausgebremst, Changelogs fehlen in den Pull Requests.

Ursache: Unauthentifizierte API-Anfragen gegen github.com sind stark begrenzt. Ohne eigenen Token läuft der Bot schnell ins Limit, auch wenn die Zielplattform GitLab ist.

Prüfung: LOG_LEVEL=debug setzen und im Log nach Rate-Limit-Warnungen gegen api.github.com suchen. Es dürfen keine auftreten.

Lösung: RENOVATE_GITHUB_COM_TOKEN mit einem persönlichen github.com-Token setzen, ausdrücklich für das Abholen von Changelogs.

12. Geteilte Presets werden nicht gefunden

Symptom: Presets aus einem eigenen Repository greifen nicht, oder es erscheinen Deprecation-Warnungen.

Ursache: npm-basierte Presets sind deprecated und sollen in einem künftigen Major-Release entfallen. Zusätzlich ist renovate.json als Default-Dateiname für geteilte Presets deprecated.

Prüfung:

npx --yes --package renovate -- renovate-config-validator --no-global default.json

Lösung: Die Preset-Datei im Preset-Repository in default.json umbenennen und von npm-basierten auf Repo-basierte Presets umstellen. Presets müssen in JSON, JSONC oder JSON5 vorliegen, andere Formate werden nicht unterstützt.

Plattformen, Token und Versionswechsel

13. Berechtigungsfehler in der GitHub Action

Symptom: Renovate scheitert als GitHub Action mit Berechtigungsfehlern, obwohl ein Token gesetzt ist.

Ursache: Der eingebaute GITHUB_TOKEN hat zu enge Rechte und taugt nicht zur Authentifizierung von Renovate. Für Updates an Workflow-Dateien durch den github-actions-Manager verlangt die Dokumentation zusätzlich den workflow-Scope. Ohne ihn bleiben diese Dateien unverändert.

Prüfung: Workflow-Lauf starten und im Log kontrollieren, dass die Plattform-Authentifizierung fehlerfrei durchläuft und Repositories gelistet werden.

Lösung: Klassischen Personal Access Token anlegen, mit repo:public_repo für nur öffentliche beziehungsweise repo für auch private Repositories. Bei Workflow-Updates zusätzlich workflow. Als secrets.RENOVATE_TOKEN hinterlegen.

14. GitLab: Trockenlauf grün, echter Lauf bricht ab

Symptom: --dry-run läuft sauber durch, beim echten Lauf scheitert das Anlegen der Merge Requests.

Ursache: Für Trockenläufe genügt der Token-Scope read_api, für echte Läufe wird api benötigt. Der Renovate Runner verlangt zusätzlich read_user und write_repository.

Prüfung: Erst mit --dry-run=full testen, danach einen echten Lauf starten und kontrollieren, ob ein Merge Request entsteht.

Lösung: GitLab-PAT mit den Scopes read_user, api und write_repository neu ausstellen und als CI-Variable RENOVATE_TOKEN hinterlegen. Project Access Tokens sind laut Dokumentation nicht empfehlenswert, wenn Renovate mehrere Projekte betreut, weil Konfiguration und Token pro Projekt einzeln eingerichtet werden müssten.

15. GitLab ignoriert die automergeStrategy

Symptom: Die konfigurierte Merge-Strategie wird auf GitLab nicht angewendet.

Ursache: automergeStrategy ist für die GitLab-Plattform nicht implementiert. Alle Werte verhalten sich, als wäre auto gesetzt.

Prüfung: Am gemergten Renovate-Merge-Request nachsehen, welche Merge-Methode GitLab tatsächlich verwendet hat.

Lösung: Die Option auf GitLab nicht als Steuerungsmittel einplanen. Das Merge-Verhalten stattdessen über die GitLab-Projekteinstellungen regeln.

16. Das Dependency Dashboard erscheint nicht

Symptom: Es wird ein Dependency Dashboard erwartet, das Issue taucht aber nicht auf.

Ursache: Zwei Gründe kommen infrage. Erstens hat die Option dependencyDashboard den Default false. Aktiv wird das Dashboard erst dadurch, dass config:recommended das Preset :dependencyDashboard einbindet. Wer ohne dieses Preset fährt, bekommt kein Dashboard. Zweitens setzt das Dashboard eine Plattform mit Issues und dynamischen Markdown-Checkboxen voraus. Auf Azure, Bitbucket, Bitbucket Server, Gerrit und SCM-Manager steht es nicht zur Verfügung.

Prüfung: In der aufgelösten Konfiguration nachsehen, ob :dependencyDashboard über ein Preset eingebunden ist oder dependencyDashboard explizit auf true steht. Danach im Repository nach dem Dashboard-Issue suchen.

Lösung: {"dependencyDashboard": true} explizit setzen oder das Preset :dependencyDashboard einbinden. Auf einer Plattform ohne Issue-Unterstützung stattdessen über Labels und prConcurrentLimit steuern.

17. Nach dem Upgrade auf Version 43 startet der Bot nicht mehr

Symptom: Renovate 43 startet nicht, oder Gradle-Wrapper-Updates bleiben aus.

Ursache: Die package.json von Renovate setzt engines.node auf ^24.11.0, die Release-Notes zu 43.0.0 nennen Node 24 als Mindestanforderung. Zusätzlich ist die Ausführung des Gradle Wrapper per Default abgeschaltet, und postUpgradeTasks laufen nicht mehr im Shell-Modus. Auch binarySource=docker ist offiziell deprecated, und Renovate wird nun als ESM ausgeliefert. Die vollständige Liste steht in den Release-Notes zu 43.0.0.

Prüfung:

node --version && npx --yes --package renovate -- renovate --version

Die Node-Ausgabe muss im Bereich v24.11.0 bis unterhalb von v25 liegen, den ^24.11.0 abdeckt.

Lösung: Node in diesen Bereich bringen. Gradle-Wrapper-Updates über allowedUnsafeExecutions mit dem Wert gradleWrapper freigeben. Die Option akzeptiert die Werte bazelModDeps, goGenerate, gradleWrapper und mise. Shell-Semantik für postUpgradeTasks bei Bedarf über allowShellExecutorForPostUpgradeCommands=true reaktivieren.

18. Nach Version 43 plötzlich mehr Pull Requests

Symptom: Trotz konfigurierter Gruppierung entstehen nach dem Upgrade mehr Pull Requests als vorher.

Ursache: Seit 43.0.0 lassen sich Replacements und Lockfile-Maintenance nicht mehr mit anderen Updates gruppieren. Zusätzlich führt config:best-practices nun wöchentliche Lockfile-Wartung durch.

Prüfung: Nach dem nächsten Lauf die Zahl offener Renovate-Pull-Requests gegen prConcurrentLimit abgleichen, Default ist 10.

Lösung: Die Lockfile-Wartung bei Bedarf abwählen über "ignorePresets": [":maintainLockFilesWeekly"]. Ansonsten prConcurrentLimit und prHourlyLimit als Bremse nutzen. Der Default von prHourlyLimit ist 2, der Wert 0 hebt das Stundenlimit auf.

19. Nach Version 42 werden Updates zurückgehalten

Symptom: Updates, die früher sofort kamen, erscheinen erst mit Verzögerung.

Ursache: minimumReleaseAge verlangt seit 42.0.0 per Default einen Release-Zeitstempel. Wer config:best-practices nutzt, bekommt über security:minimumReleaseAgeNpm zusätzlich eine Wartezeit von drei Tagen für npm-Pakete.

Prüfung: Im Dependency Dashboard beziehungsweise im Debug-Log nachlesen, mit welcher Begründung ein Update zurückgehalten wird.

Lösung: Für das alte Verhalten minimumReleaseAgeBehaviour=timestamp-optional setzen. Die npm-Karenz lässt sich über ignorePresets abwählen, wenn sie nicht gewollt ist. Wer von einer älteren Version kommt und yarn-plugin-catalogs einsetzt, muss vor dem Upgrade migrieren, die offizielle Yarn-Catalog-Unterstützung ersetzt das Community-Plugin.

Was diese Sammlung nicht ersetzt

Jeder Fall hier ist an ein dokumentiertes Verhalten geknüpft. Was Renovate in Ihrem Repository tatsächlich sieht, beantwortet dagegen nur ein Trockenlauf mit --dry-run=extract gegen genau dieses Repository. Ich halte den Validator im CI-Job und den Extract-Trockenlauf vor jeder Konfigurationsänderung für die zwei Maßnahmen, die den größten Teil dieser Liste gar nicht erst entstehen lassen. Der Weg dorthin steht im Hauptbeitrag Updates, die sich selbst vorschlagen: Abhängigkeiten mit Renovate.

Sie wollen Ihre Abhängigkeiten aktuell halten, ohne dass es zur Daueraufgabe wird? Ich baue automatisierte Update-Strecken, in denen jede Änderung erst getestet und dann übernommen wird. Mehr unter IT-Automatisierung, das Erstgespräch ist unverbindlich.