Renovate mit GitLab nutzen

19.05.2025, Christian Mäder

Den Renovate Bot auf GitHub zu nutzen, ist kinderleicht: Es reicht, die entsprechende GitHub App für sein Repository zu konfigurieren. Das Einrichten auf GitLab ist leider etwas aufwendiger. Diese Anleitung hilft, den Renovate Bot auf gitlab.com einzurichten.

Renovate Repository

Der Renovate Bot auf GitLab sollte in einem neuen, eigenen GitLab Repository konfiguriert werden. Es enthält die Konfiguration für den Runner. Zudem machen wir uns die GitLab CI/CD-Funktion zu nutzen, indem wir eine Scheduled Pipeline anlegen. Aber der Reihe nach.

Im neuen, leeren Git-Repository zuerst einmal ein neues File .gitlab-ci.yml anlegen. Das File soll nun mit folgendem Inhalt befüllt werden:

stages:
  - lint
  - test
  - deploy

include:
  - project: 'renovate-bot/renovate-runner'
    file: 'templates/renovate.gitlab-ci.yml'
    ref: v22.0.0
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-config-validator.gitlab-ci.yml'
    ref: v22.0.0

renovate-config-validator:
  needs: []
  rules:
    - if: $CI_PIPELINE_SOURCE == "web"
      when: never
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

renovate:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "web"
  needs: []
  variables:
    RENOVATE_CONFIG_FILE: config.json

Für eine private GitLab-Instanz wird am einfachsten das Repository gitlab.com/renovate-bot/renovate-runner auf die eigene Instanz gespiegelt. Der Pfad unter project: muss dann entsprechend angepasst werden. Alternativ können die Files auch direkt von gitlab.com geladen werden:

include:
  - remote: 'https://gitlab.com/renovate-bot/renovate-runner/-/raw/v22.0.0/templates/renovate.gitlab-ci.yml'
include:
  - remote: 'https://gitlab.com/renovate-bot/renovate-runner/-/raw/v22.0.0/templates/renovate-config-validator.gitlab-ci.yml'

Jedoch kann es sein, dass Renovate diese URLs nicht automatisch aktualisieren kann. Dann müsste die Versions-Nummer (v22.0.0) manuell nachgeführt werden.

Als nächstes muss das File config.json angelegt werden. Dieses File wird durch den Renovate Bot gelesen und steuert, wie sich dein eigener Renovate Bot verhalten soll.

Folgender Inhalt kann grundsätzlich übernommen werden. Einige Werte müssen jedoch unbedingt angepasst werden! Andere Werte können nach eigenem Belieben angepasst werden.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "gitAuthor": "Renovate Bot <renovate@localhost>",
  "autodiscover": true,
  "autodiscoverFilter": [
    "your_username_or_group/**"
  ],
  "onboarding": true,
  "repositoryCache": "enabled",
  "prHourlyLimit": 5,
  "configMigration": true,
  "minimumReleaseAge": "1 day",
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": [
        "^wrangler.toml$"
      ],
      "matchStrings": [
        "HUGO_VERSION\\s*=\\s*\"(?<currentValue>.*?)\"\\n"
      ],
      "datasourceTemplate": "docker",
      "depNameTemplate": "ghcr.io/gohugoio/hugo",
      "extractVersionTemplate": "^v(?<version>.*)$"
    }
  ]
}

Wichtig! In der eben erstellten Datei config.json müssen nun einige Werte angepasst werden:

• gitAuthor:
  Dies ist der Name und die E-Mail-Adresse, welche der Renovate Bot nutzt, um seine Git-Commits zu machen. Für viele Projekte ist es wichtig, dass es diesen Nutzer gibt. Für private Projekte empfehle ich, den Namen Renovate Bot und deine eigene E-Mail-Adresse zu verwenden. Das sieht dann etwa so aus: Renovate Bot <[email protected]>. Für geschäftliche Projekte empfehle ich, einen entsprechenden (technischen) GitLab-User anzulegen und dessen E-Mail-Adresse zu verwenden, beispielsweise Renovate Bot <[email protected]>.
• autodiscoverFilter:
  Der Renovate Bot nutzt diese Filter, um die Repositories zu finden, für die es Merge Requests erstellen soll. Typischerweise setzt du diesen Filter auf dein_username/** oder deine_gruppe/**. Du kannst mehrere Filter angeben, bspw. ["dein_username/**", "deine_gruppe/**"]. Nutzt du die öffentliche GitLab Instanz gitlab.com, dann würde der Renovate Bot mit der letzten Angabe seine Merge Requests für alle Repositories unter gitlab.com/dein_username und gitlab.com/deine_gruppe erstellen.

Eine Beschreibung der anderen oben konfigurierten Parameter – sowie aller möglichen Parameter – findest du in der entsprechenden Dokumentation.

Die zwei eben angelegten Dateien .gitlab-ci.yml und config.json (sowie einige weitere Einstellungen in GitLab, zu denen wir noch kommen) sind grundsätzlich alles, was du brauchst, um den Renovate Bot laufen zu lassen. Du kannst nun also einen Commit machen und diesen auf GitLab pushen.

Beim Push wird GitLab eine CI/CD-Pipeline anlegen. In dieser Pipeline wird der Renovate Bot prüfen, ob die angegebene Konfiguration in config.json gültig ist. Damit der Renovate Bot nun aber regelmässig läuft, sind noch zwei weitere Einstellungen zu machen.

GitLab Token

Der Renovate Bot muss auf die API von GitLab zugreifen, damit er deine Projekte finden und darin Merge Requests erstellen kann. Dazu muss ein GitLab Access Token konfiguriert werden. Es gibt zwei unterschiedliche Empfehlungen dafür, je nachdem, ob du Renovate Bot für dich privat konfigurierst oder für dein Unternehmen.

Privater Renovate Bot

Wenn du den Renovate Bot für deine privaten Repositories einsetzt, dann musst du in deinen GitLab Einstellungen ein neues Personal Access Token erstellen. Welche Angaben du machen musst, liest du im übernächsten Abschnitt.

Geschäftlicher Renovate Bot

Richtest du den Renovate Bot für deine Firma oder eine GitLab-Gruppe (bspw. ein Open-Source Projekt) ein, solltest du auf Group Access Tokens zurückgreifen. Der Renovate Bot wird dann auf alle Projekte zugreifen können, welche Teil der Gruppe sind, auf welcher das Token erstellt wurde. Dies verhindert, dass der Renovate Bot aus Versehen einige Merge Requests in Repositories erstellt, in denen er nichts zu suchen hat.

Um Group Access Tokens zu erstellen, gehe auf die Seite der entsprechenden Gruppe in GitLab. Dann kannst du unter Settings das Menu Access Tokens auswählen. Darin erstellst du nun ein neues Group Access Token.

GitLab Token für den Renovate Bot

Das Token sollte die Scopes api, read_repository und write_repository haben. Nenne das Token Renovate Bot oder ähnlich – der Name spielt keine Rolle und dient nur zur Wiedererkennung. Du kannst das Ablaufdatum löschen, dann erstellt GitLab ein Token mit maximaler Gültigkeit (zurzeit 365 Tage). Wenn du das Token erstellt hast, kopiere es unbedingt in die Zwischenablage. GitLab wird dir das Token nie mehr anzeigen.

Nun musst du das Token in deinem Renovate Projekt als CI/CD-Variable hinterlegen. Gehe dazu auf die Seite deines Renovate Projektes. Dann unter Settings das Menu CI/CD auswählen. Nun kannst du unter Variables eine neue Variable angelegen. Diese muss RENOVATE_TOKEN heissen. Der Wert entspricht dem eben erstellten GitLab Token. Ich empfehle, als Visibility den Typ Masked and hidden zu wählen. Damit wird verhindert, dass eine andere Person mit Zugriff auf das Repository das Token einfach extrahieren kann.

GitHub Token

Der Renovate Bot macht viele Requests zu GitHub, etwa um zu prüfen, ob von einer Drittkomponente eine neue Version verfügbar ist. Für einige Drittkomponenten kann sich der Renovate Bot beispielsweise auch Changelogs holen und diese als Teil des Merge Requests anzeigen. Damit der Renovate Bot nicht ins strikte Rate-Limit der GitHub API läuft, das für anonyme Zugriffe gilt, muss ein GitHub Access Token erstellt werden.

Bei GitHub können unseres Wissens nach Access Tokens mit entsprechender Reichweite nur als Personal Access Tokens erstellt werden – sie gehören somit immer zu einem bestimmten Benutzer. Für geschäftliche Installationen lohnt es sich, bei GitHub einen eigenen Benutzer anzulegen.

In den Einstellungen von GitHub musst du Developer Settings wählen. Dann kannst du unter Personal Access Tokes ein neues Token erstellen. Bei GitHub kannst du Tokens ohne Gültigkeitsbeschränkung erstellen. Wähle bei Repository Access den Wert All Repositories. Ansonsten musst du keine weiteren Berechtigungen auswählen.

Wenn du das Token erstellt hast, kopiere es wieder in die Zwischenablage. Erstelle im Repository für dein Renovate Bot eine weitere CI/CD-Variable: RENOVATE_GITHUB_COM_TOKEN. Wähle wieder Masked and hidden aus.

Scheduled Pipeline

Nun ist dein Renovate Bot schon fast bereit. Es fehlt nur noch die Konfiguration, dass GitLab den Bot regelmässig laufen lässt.

Wenn du in deinem GitLab Repository für deinen Renovate Bot bist, kannst du das unter Build und dann Pipeline Schedules erwirken. Klicke auf New Schedule. Wähle die entsprechende Zeitzone, die für dich oder für dein Unternehmen relevant ist.

Als Interval Pattern kannst du nun einen der Vorschläge auswählen. Oder du gibst eine eigene Cron Expression an. Wenn du nicht weisst, wie dies geht, empfehle ich dir die Website crontab.guru.

Wir nutzen den Cron-Ausdruck 20,50 6-16 * * 1-5, dieser hat sich bei uns bewährt. Es bedeutet, dass unser Renovate Bot von Montag bis Freitag (1-5) zwischen 6 und 16 Uhr (6-16) jeweils jede halbe Stunde um 20nach und 10vor (20,50) läuft.

Berücksichtigt werden sollte, wie lange ein Durchgang des Renovate Bots dauert. Bei uns dauert ein Durchgang im Durchschnitt rund 15 Minuten. Somit kann der Renovate Bot gut jede 30 Minuten laufen.

Dauert der Durchgang länger, sollte der Renovate Bot weniger häufig gestartet werden. Oder es müssen mehrere Schedules eingerichtet werden, die jeweils unterschiedliche autodiscoverFilter haben. Dies kann mittels der Umgebungsvariable RENOVATE_AUTODISCOVER_FILTER erreicht werden.

Testlauf

Wenn deine Pipeline nun eingerichtet ist und die entsprechende Startzeit nicht in den nächsten Minuten eintritt, kannst du die Pipeline auch manuell starten.

Bei den ersten Versuchen solltest du beobachten, was der Renovate Bot in sein Log schreibt. Du findest es als Teil der Pipeline.

Onboarding

Der Renovate Bot wird nun bei allen Repositories, welche es aufgrund des autodiscoverFilter findet, einen Merge Request erstellen. In diesem Merge Request schlägt der Renovate Bot vor, die Datei renovate.json zu erstellen.

Diese Datei steuert den Renovate Bot für das entsprechende Repository. Der Renovate Bot kann seine Merge Requests auch gleich automatisch mergen, etwa sobald die Build-Pipline des Projektes erfolgreich durchgelaufen ist.

Wir haben dies für das Renovate Projekt bei uns so konfiguriert. Der Renovate Bot aktualisiert sich somit selbst. Dazu muss die Datei renovate.json wie folgt angepasst (oder angelegt) werden:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    ":disableDependencyDashboard"
  ],
  "automerge": true
}

Onboarding Konfiguration anpassen

Bei uns mögen wir die Funktion Dependency Dashboard des Renovate Bots nicht. Deshalb haben wir die Standard-Konfiguration angepasst.

Dafür kann ein neues Repository erstellt werden. Der Slug für das Repository muss unbedingt renovate-config sein. Das Repository wird vom Renovate Bot hierarchisch gesucht.

Für das fiktive Repository gitlab.com/nxt/public/renovate/runner würde der Renovate Bot folgende Repositories suchen:

1. gitlab.com/nxt/public/renovate/renovate-config
2. gitlab.com/nxt/public/renovate-config
3. gitlab.com/nxt/renovate-config

In diesem Repository mit dem renovate-config Slug schaut der Renovate Bot nach einer Datei mit dem Namen default.json. Unser default.json sieht folgendermassen aus:

{
    "$schema": "https://docs.renovatebot.com/renovate-schema.json",
    "extends": [
        "config:recommended",
        ":disableDependencyDashboard"
    ]
}

Fazit

Das Konfigurieren eines Renovate Bots für seine eigenen GitLab Projekte ist keine übermässig grosse Sache. Sie ist in kurzer Zeit erledigt. Von da hilft der Renovate Bot mit, dass die Drittkomponenten stets aktuell bleiben.

Renovate Bot ist äusserst dynamisch anpassbar. Das macht die Software nicht immer ganz einfach zu verstehen. Die Dokumentation ist zwar ausführlich, erfordert jedoch an einigen Stellen ein gutes Verständnis der Zusammenhänge.

Der Einsatz des Renovate Bots lohnt sich für uns. Er leistet einen erheblichen Beitrag, dass unsere Software-Projekte fast automatisch auf dem neuesten Stand bleiben.