Versions-Updates

Versions-Updates ist der Weg mit gehostetem Renovate innerhalb der Abhängigkeits-Updates. Aktiviere ihn für eine Organisation, und fremforge öffnet gebündelte, gut reviewbare Pull Requests nach dem Zeitplan, den deine renovate.json festlegt: npm, gomod, Terraform-Provider, Basis-Images in Dockerfiles, Helm-Charts und jede eigene Regex-Festlegung. Die Repositorys jeder angemeldeten Organisation werden jede Nacht durchlaufen; siehe Takt.

Verwundbare Abhängigkeiten, die deine Scans finden, sind Sache des anderen Wegs: Sicherheitskorrekturen öffnen einen Pull Request pro verwundbarem Paket. Bis der Weg Sicherheitskorrekturen für deine Organisation übernimmt, öffnet gehostetes Renovate außerdem eigene Sicherheits-Pull-Requests für OSV-Advisories, wie unten beschrieben.

Im Tarif von 30 € pro Nutzer enthalten. Keine Zusatzstufe, keine Action-Minuten bei Dritten, kein GitHub (das Unternehmen) im Datenpfad.

Was du bekommst

• Automatische Pull Requests für veraltete Abhängigkeiten, sinnvoll gebündelt: ein Pull Request pro zusammengehöriger Paketgruppe statt Dutzender einzeiliger Versionssprünge.
• Pull Requests, die durch Schwachstellen ausgelöst werden, für veröffentlichte Sicherheits-Advisories (OSV), geöffnet vom nächsten Lauf statt erst nach deinem Zeitplan und nicht durch die unter Plattformrichtlinie beschriebene Wartezeit für das Release-Alter zurückgehalten (für npm siehe die eine Ausnahme dort). Sobald der Weg Sicherheitskorrekturen für eine Organisation übernimmt, werden diese dort abgeschaltet, sodass eine Korrektur immer nur einmal vorgeschlagen wird.
• Ein Renovate-Issue Dependency Dashboard in jedem Repository, mit dem Status auf einen Blick.
• Das vollständige Renovate-Konfigurationsschema: Jede Option von docs.renovatebot.com funktioniert unverändert auf fremforge. Deine Regeln werden auf die Plattformrichtlinie angewendet.
• Ein Bot-Benutzer pro Mandant, <org>-fremforge-bot-deps, nur auf deine Organisation beschränkt; sein Token überschreitet nie Mandantengrenzen. Sicherheitskorrekturen verwenden denselben Bot.
• EU-souverän: läuft auf T Cloud Public CCE, ohne SaaS von Dritten im Datenpfad.

Aktivieren

1. Öffne Sicherheit › Beheben › Abhängigkeits-Updates (oder Build und Deployment › Abhängigkeits-Updates) und wechsle zu Versions-Updates.
2. Aktiviere gehostetes Renovate.
3. fremforge richtet einen Bot-Benutzer pro Mandant ein, <org>-fremforge-bot-deps, und gibt ihm Schreibzugriff auf die Repositorys deiner Organisation.
4. Die Repositorys werden vom nächsten nächtlichen Lauf erfasst, oder sofort mit Jetzt ausführen; Pull Requests folgen dann dem Zeitplan in deiner renovate.json.

Mit dem Aktivieren erhält die Organisation außerdem die Standardeinstellungen der Sicherheitskorrekturen: Korrektur-Pull-Requests per Klick, die auf ein Review warten.

Der Bot-Benutzer wird von fremforge verwaltet. Du musst ihn weder anlegen noch seine Zugangsdaten rotieren oder dir Sorgen um verlorene Passwörter machen. Das Token wird von der Plattform verwaltet und automatisch rotiert.

Deaktivieren

1. Sicherheit › Beheben › Abhängigkeits-Updates → Versions-Updates → gehostetes Renovate deaktivieren.
2. fremforge widerruft das Token des Bots sofort und entfernt den Bot aus deiner Organisation, es sei denn, die Sicherheitskorrekturen stehen auf einem automatischen Modus: Dann bleibt der Bot, nur noch für Sicherheitskorrekturen.
3. Pull Requests, die Renovate bereits geöffnet hat, bleiben offen. Merge oder schließe sie wie jeden anderen Pull Request.
4. Die renovate.json der Organisation bleibt in deinen Repositorys; fremforge fasst sie nicht an.

Beim erneuten Aktivieren wird ein frischer Bot eingerichtet. Der vorherige Bot-Benutzername wird stillgelegt (nicht wiederverwendet), damit die Audit-Historie eindeutig bleibt.

Plattformrichtlinie

Jeder Lauf beginnt mit der Richtlinie von fremforge, und deine renovate.json wird darauf angewendet.

• Takt. Die Repositorys jeder angemeldeten Organisation werden jede Nacht (ab 02:30 UTC) für einen Lauf eingereiht; ein Repository, das in den letzten 4 Stunden gelaufen ist, wird übersprungen. Ein schedule in deiner renovate.json begrenzt weiterhin, wann routinemäßige Pull Requests geöffnet werden. Sicherheitsupdates (Schwachstellenwarnungen) ignorieren diesen Zeitplan und die Wartezeit für das Release-Alter und werden vom nächsten Lauf nach Veröffentlichung der Advisory geöffnet. Jetzt ausführen startet einen Lauf außerhalb des Takts.
• Wartezeit für das Release-Alter. Ein routinemäßiges Update wird erst vorgeschlagen, wenn die neue Version so alt ist wie das Release-Alter deiner Organisation (3 Tage, sofern ein Owner es nicht geändert hat), sodass dich ein bösartiges oder fehlerhaftes Release, das innerhalb weniger Tage zurückgezogen wird, nie erreicht. Registrys, die kein Veröffentlichungsdatum angeben, bekommen keine Wartezeit. Sicherheitsupdates überspringen die Wartezeit, mit einer Ausnahme für npm: Eine korrigierte Version, die jünger als das Release-Alter ist, wird nur angeboten, wenn die Advisory-Daten von npm sie als Korrektur für deine aktuelle Version aufführen. Eine Korrektur, die diese Daten nicht aufführen, wartet wie ein routinemäßiges Update.
• Die Wartezeit gilt auch für deine Lockfile. Renovate schlägt eine Version vor, und dein Paketmanager löst dann die Lockfile auf, einschließlich neuer transitiver Abhängigkeiten. Für npm, pnpm und Yarn 1 läuft diese Auflösung über die Release-Alter-Sicht von fremforge auf die npm-Registry, sodass eine Bereichsanhebung keine Version festlegen kann, die jünger als 3 Tage ist. Die Sicht verwendet für jede Organisation 3 Tage; bei einem längeren Release-Alter hält der unten beschriebene Check den Pull Request zurück, bis die Lockfile alt genug ist. Deine eigene .npmrc wird danach weiterhin angewendet, sodass deine privaten Scopes und jede eigene registry=-Zeile Vorrang haben. Yarn 2+ liest stattdessen .yarnrc.yml und ist von der Sicht nicht abgedeckt; der Check unten hält diese Pull Requests trotzdem zurück.
• Check fremforge/release-age. Jeder Pull Request bekommt diesen Check, und er ist ein erforderlicher Check im Branch-Schutz. Bei einem Pull Request für ein Abhängigkeits-Update bleibt er ausstehend und zeigt „Waiting until …", bis jede Version, die die Lockfile auflöst, so alt ist wie dein Release-Alter. Danach wird er innerhalb weniger Minuten von selbst grün, ohne neuen Push, und der Automerge wartet auf ihn. Eine Version, die eine geprüfte Advisory (jedes Schweregrads) auf deinem Basis-Branch als ihre Korrektur nennt, wartet stattdessen 24 Stunden, ebenso eine neue Abhängigkeit, die nur diese Korrektur von denselben Herausgebern mitgebracht hat (der Sicherheitskorrektur-Weg). Eine Korrektur für eine bekanntermaßen ausgenutzte Schwachstelle wird nicht zurückgehalten. Bei einem Pull Request, den eine Person geöffnet hat, werden frische Versionen gemeldet, halten den Pull Request aber nicht zurück. Stellst du den Scanner für eine Organisation oder ein Repository auf off, wird der Check innerhalb einer Stunde aus dem Branch-Schutz entfernt.
• Automerge. Patch-, Pin- und Digest-Updates werden standardmäßig bei grüner CI automatisch gemergt. Minor-Updates werden automatisch gemergt, wenn du das in den Richtlinieneinstellungen einschaltest. Major-Updates warten immer auf deine Freigabe im Dependency Dashboard.
• Pakete mit großer Tragweite. Rund 30 Pakete für Authentifizierung, Kryptografie, Datenbanken, ORMs und Cloud-KMS (zum Beispiel jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) mergen ein routinemäßiges Update nie automatisch; der Pull Request wartet auf ein Review. OpenID-Bibliotheken dürfen einen Patch automatisch mergen, aber nie ein Minor- oder Major-Update.
• Sicherheitsupdates. Ob die eigenen Sicherheits-Pull-Requests von gehostetem Renovate bei grüner CI automatisch gemergt werden, bestimmt die Einstellung Wann Korrekturen gemergt werden der Sicherheitskorrekturen: Zusammenführen, wenn die Prüfungen bestehen oder Auf Review warten (der Standard). Organisationen, bei denen der frühere Automerge für Security updates eingeschaltet war, was für jede angemeldete Organisation der Standard war, wurden auf Zusammenführen, wenn die Prüfungen bestehen umgestellt, sodass sich für sie nichts geändert hat. Damit wird ein Sicherheits-Pull-Request für jedes Paket automatisch gemergt, auch für die mit großer Tragweite: Das sind genau die Bibliotheken, die du am schnellsten gepatcht haben willst. Siehe Mergen.
• Merge-Fenster. Ein Admin der Organisation kann einschränken, wann Renovate-Pull-Requests zum Mergen scharfgeschaltet werden, in ganzen UTC-Stunden an ausgewählten Wochentagen (merge_window in PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). Außerhalb des Fensters wird kein Renovate-Pull-Request scharfgeschaltet, und Scharfschaltungen des Bots werden aufgehoben, wenn sich das Fenster schließt; eine Scharfschaltung durch eine Person bleibt unberührt. Ein Repository mit einem offenen Issue mit dem Label release-freeze wird nie scharfgeschaltet.
• Korrekturen für bekanntermaßen ausgenutzte Schwachstellen. Ein Sicherheitsupdate für eine CVE, die aktiv ausgenutzt wird (gelistet in der EU Vulnerability Database von ENISA oder im Katalog Known Exploited Vulnerabilities von CISA, täglich geprüft), wird im Lauf vor jedem anderen Update geöffnet, nicht durch die PR-Limits zurückgehalten und trägt das Label known-exploited (sofern dein Repository dieses Label hat) sowie einen Hinweis in der Beschreibung des Pull Requests. Er wird außerdem außerhalb des Merge-Fensters scharfgeschaltet, sodass er gemergt wird, sobald seine Checks bestanden sind. Nur das Fenster wird übersprungen: Ein Pull Request wird außerhalb nur dann scharfgeschaltet, wenn er auch innerhalb scharfgeschaltet worden wäre, und der Release-Freeze, eine Person, die den Automerge aufhebt, sowie deine erforderlichen Checks gelten weiterhin.
• Deine Regeln haben Vorrang. Regeln in deiner renovate.json werden nach dieser Richtlinie angewendet, sodass eine Regel automerge: true dort sie übersteuert, einschließlich der Review-Pflicht für Pakete mit großer Tragweite. Fügst du eine solche Regel hinzu, nimm diese Pakete davon aus (siehe das Beispiel unten).

Einstellungen

Ein Owner legt die Richtlinie des Wegs auf der Seite fest, oder mit PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (Scope dependency-updates:write). Jedes Feld ist optional; ein weggelassenes behält seinen Wert, und ein unbekanntes Feld wird mit unknown-field abgewiesen.

GET auf demselben Pfad liefert dieselben Felder in derselben snake_case-Schreibweise. security_automerge ist hier kein Feld: Ob Sicherheits-Pull-Requests sich selbst mergen, ist die Einstellung merge der Sicherheitskorrekturen, und security_automerge an diesen Pfad zu senden, wird mit einer entsprechenden Meldung abgewiesen.

Konfigurieren

Die Konfiguration pro Repository erfolgt über renovate.json im Wurzelverzeichnis des Repositorys. Ohne sie verwendet Renovate sinnvolle Standardwerte, was für den ersten Monat meist genügt, solange du siehst, welche Art von Pull Requests eintreffen.

Ein minimaler Einstieg:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "schedule": ["before 4am on the first day of the month"]
}

Eine Konfiguration mit mehr eigener Handschrift, die OpenTelemetry-Pakete bündelt, Patch- und Lockfile-Updates automatisch mergt und für Major-Updates ein menschliches Review verlangt:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard", ":semanticCommits"],
  "timezone": "Europe/Copenhagen",
  "schedule": ["before 4am on the first day of the month"],
  "vulnerabilityAlerts": {
    "labels": ["security"],
    "schedule": ["at any time"]
  },
  "packageRules": [
    {
      "matchPackagePatterns": ["^@opentelemetry/"],
      "groupName": "opentelemetry"
    },
    {
      "matchUpdateTypes": ["patch", "pin", "digest", "lockFileMaintenance"],
      "automerge": true,
      "platformAutomerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["major-bump"]
    }
  ]
}

Die automerge-Regel in diesem Beispiel wird nach der Plattformrichtlinie angewendet und würde daher auch die Pakete für Authentifizierung, Kryptografie und Datenbanken automatisch mergen, die fremforge sonst für ein Review zurückhält. Sollen diese manuell bleiben, nimm sie von der Regel aus, zum Beispiel mit "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

Die vollständige Referenz der Renovate-Konfiguration steht unter docs.renovatebot.com/configuration-options/.

Was aktualisiert wird

Renovate erkennt die meisten Ökosysteme ohne Konfiguration. Automatisch erkannte Ökosysteme auf fremforge:

• npm / pnpm / yarn: package.json plus Lockfile-Pflege
• Go-Module: go.mod
• OpenTofu / Terraform: Provider-Versionen in versions.tf
• Dockerfile: FROM-Zeilen, optional mit Festlegung per Digest
• Helm: Chart-Versionen in values.yaml und Chart.yaml
• Eigene Regex-Festlegungen: für jeden Versions-String in jeder Datei (ideal, um Binärdateien festzulegen, die per Shell-Skript installiert werden)
• Python: pyproject.toml, requirements*.txt, Pipfile und Poetry. Per Hash festgelegte Requirements, die mit uv pip compile oder pip-compile kompiliert wurden, werden als Ganzes neu gesperrt; siehe Kompilierte Python-Requirements.

Die vollständige Ökosystem-Matrix steht unter docs.renovatebot.com/modules/manager/.

Kompilierte Python-Requirements

Eine requirements*.txt, die von uv pip compile oder pip-compile geschrieben wurde, legt jedes Paket fest, oft mit --hash-Zeilen. Manche Updates erfordern, dass sich eine weitere Festlegung mitbewegt. So legt pydantic zum Beispiel pydantic-core auf eine exakte Version fest. Nennt der Kopf der Lock-Datei den Befehl, der sie geschrieben hat, führt gehostetes Renovate diesen Befehl mit --upgrade-package erneut aus, sodass der Update-Pull-Request die gesamte neu gesperrte Datei enthält: das aktualisierte Paket, jede Festlegung, die es mitbewegt, und ihre Hashes. Ohne das erneute Sperren ändert der Pull Request eine Zeile, und pip install --require-hashes weist ihn ab.

Gehostetes Renovate tut das für jede requirements*.txt, deren Kopf einen Compile-Befehl enthält, in jeder Organisation. Du musst nichts konfigurieren, solange der Kopf den Regeln von Renovate folgt:

• Verwende lange Optionsnamen und verbinde jeden Wert mit =, zum Beispiel --output-file=requirements.txt, --python-version=3.11, --extra=dev und --group=dev. uv schreibt den Befehl genau so in den Kopf, wie du ihn eingegeben hast. Renovate weist -o requirements.txt und --python-version 3.11 ab und lässt diese Lock-Datei dann unverändert.
• Nenne die Quelldatei, zum Beispiel uv pip compile pyproject.toml .... Ein Kopf ohne Quelldatei (zum Beispiel uv pip compile --group render ...) wird nicht neu gesperrt.
• Gib jeder direkten Abhängigkeit eine Versionsbeschränkung. Eine Abhängigkeit ganz ohne Version ("httpx") wird nicht neu gesperrt; ihr Update ändert nur ihre eigene Zeile. Eine Untergrenze wie "httpx>=0.28" genügt.

Ein Kopf, der funktioniert:

# This file was autogenerated by uv via the following command:
#    uv pip compile pyproject.toml --extra=dev --universal --python-version=3.11 --generate-hashes --output-file=requirements-dev.txt

Renovate behält --python-version beim erneuten Sperren bei, setze den Wert also auf die älteste Python-Version, die du unterstützt. Die neu gesperrte Datei ist dieselbe Datei, die dein eigener Compile-Lauf erzeugen würde, und sie enthält keine Index-URL.

Das erneute Sperren löst gegen das öffentliche PyPI auf, denselben Index, mit dem Renovate die neue Version findet, sofern der Kopf oder deine pyproject.toml keinen anderen Index nennt. Eine von Hand geschriebene requirements.txt ohne Compile-Kopf wird wie bisher zeilenweise aktualisiert.

Läufe außerhalb des Takts

Du brauchst einen Renovate-Lauf vor dem nächsten geplanten Zyklus (zum Beispiel, weil du gerade eine neue renovate.json veröffentlicht hast und sehen willst, was sie erzeugt)?

1. Sicherheit › Beheben › Abhängigkeits-Updates → Jetzt ausführen.
2. Begrenzt auf einen Lauf außerhalb des Takts pro Stunde und Organisation.
3. Die Ergebnisse erscheinen innerhalb weniger Minuten unter Aktivität.

Durch Schwachstellen ausgelöste Pull Requests laufen bereits automatisch außerhalb des Takts. Du musst bei einer neuen CVE nicht auf „Jetzt ausführen" klicken; das übernimmt der eigene Schwachstellen-Scheduler von Renovate.

Takt anpassen

Das Renovate-Feld schedule akzeptiert Ausdrücke in Cron-Form. Einige gängige Muster:

• ["before 4am on the first day of the month"]: einmal im Monat. (Der Standard von fremforge ist kein Zeitplan: ein Lauf jede Nacht, und Pull Requests dürfen bei jedem Lauf geöffnet werden.)
• ["before 4am every weekday"]: täglich an Werktagen.
• ["after 9pm and before 5am"]: nur außerhalb der Geschäftszeiten.
• []: nie; verlass dich nur auf durch Schwachstellen ausgelöste Läufe.

Das Feld vulnerabilityAlerts.schedule übersteuert den Zeitplan für Sicherheits-Pull-Requests:

{
  "vulnerabilityAlerts": {
    "schedule": ["at any time"]
  }
}

Kosten

Im Tarif von 30 € pro Nutzer enthalten. Keine Abrechnung nach Verbrauch, keine Gebühr pro Pull Request, keine separate Position für Runner-Minuten.

Zum Vergleich: Dependabot von GitHub ist kostenlos, aber Dependabot-Updates, die auf Actions laufen, verbrauchen deine Actions-Minuten. Gehostetes Renovate von fremforge läuft auf von fremforge verwalteter CCE-Infrastruktur (getrennt von deinem CI-Runner-Pool, sodass es nie Runner-Minuten verbraucht). Das ist der praktische Unterschied.

Warum Renovate und nicht Dependabot

Renovate ist das OSS-Werkzeug, das wir für unsere eigenen Repositorys einsetzen, mit derselben Konfiguration, demselben Takt und derselben Form von Pull Requests, und das wir als gehostete Funktion für Abhängigkeits-Updates anbieten. Renovate unterstützt Forgejo nativ seit v37; sein Konfigurationsschema ist umfangreicher als das von Dependabot, und es funktioniert mit eigenen Regex-Festlegungen, was Dependabot nicht kann. Die meisten Teams, die beide nutzen, bevorzugen Renovate.

Du kannst Renovate auch selbst gegen deine eigenen fremforge-Repositorys betreiben, ohne dich für die gehostete Version anzumelden. Lege einfach eine renovate.json an und führe Renovate selbst in deiner CI aus. Die gehostete Version ist die Komfortschicht; die OSS-Renovate-Konfiguration, die du schreibst, ist in beiden Fällen identisch.

Private Registrys

Füge unter Sicherheit › Beheben › Abhängigkeits-Updates → Versions-Updates → Private Registries Lese-Zugangsdaten hinzu:

1. Bezeichnung: ein Name für deine eigene Übersicht (zum Beispiel „GitHub Packages").
2. Typ: npm, docker oder git (ein privater Git-Host für Modul- und Tag-Abfragen, zum Beispiel eine private Quelle für Terraform-Module).
3. Host-/Registry-URL: der Registry-Host (zum Beispiel npm.pkg.github.com) oder ein URL-Präfix mit https://. Loopback-, Metadaten- und Hosts aus privaten Adressbereichen werden abgewiesen.
4. Benutzername: nur für Docker-Basic-Auth; für npm und Git mit reinem Token leer lassen.
5. Token / Passwort: ein Token nur mit Leserechten für diese Registry.

Das Token wird verschlüsselt gespeichert (AES-256-GCM), nur für deine eigenen Renovate-Läufe verwendet, nie von der API zurückgegeben und, anders als ein Actions-Secret, nie deinen CI-Workflows zugänglich gemacht. Renovate authentifiziert sich beim nächsten Lauf an dieser Registry. Du kannst Zugangsdaten jederzeit entfernen; Abfragen für die zugehörigen Pakete schlagen dann wieder fehl, bis du sie erneut hinzufügst.

Das ist das fremforge-Gegenstück zu den Registry-Secrets von Dependabot bei GitHub.

Querverweise

• Renovate-Dokumentation (Upstream): die vollständige Konfigurationsreferenz.
• Sicherheit und Lieferkette: wie Renovate in das größere Bild der Lieferkettensicherheit passt.
• Sicherheitskorrekturen: der andere Weg, ein Pull Request pro verwundbarem Paket.
• Fehlerbehebung: wenn keine Pull Requests geöffnet werden oder ein Lauf fehlschlägt.
• Webhooks: Die Pull Requests von Renovate lösen dieselben pull_request-Webhook-Ereignisse aus wie jeder andere Pull Request.