Versie-updates

Versie-updates is het spoor van gehoste Renovate binnen Updates van afhankelijkheden. Schakel het in voor een organisatie, en fremforge opent gegroepeerde, reviewbare PR’s volgens het schema in je renovate.json: npm, gomod, Terraform-providers, base images in Dockerfiles, Helm-charts en elke eigen regex-pin. De repository’s van elke ingeschreven organisatie worden elke nacht verwerkt; zie Cadans.

Kwetsbare afhankelijkheden die je scans vinden, zijn het werk van het andere spoor: Beveiligingsfixes opent één pull request per kwetsbaar pakket. Totdat het spoor Beveiligingsfixes het voor je organisatie overneemt, opent gehoste Renovate ook zijn eigen beveiligings-pull-requests voor OSV-advisories, zoals hieronder beschreven.

Inbegrepen in het abonnement van € 30 per gebruiker. Geen extra niveau, geen actionminuten van derden, geen GitHub-het-bedrijf in het datapad.

Wat je krijgt

Automatische PR’s voor verouderde afhankelijkheden, verstandig gegroepeerd: één PR per set verwante pakketten in plaats van tientallen verhogingen van één regel.
PR’s naar aanleiding van kwetsbaarheden voor gepubliceerde beveiligingsadvisories (OSV), geopend door de volgende run in plaats van te wachten op je schema, en niet tegengehouden door de wachttijd voor de releaseleeftijd die onder Platformbeleid staat beschreven (voor npm, zie de ene uitzondering daar). Zodra het spoor Beveiligingsfixes het voor een organisatie overneemt, worden deze daar uitgezet, zodat een fix maar één keer wordt voorgesteld.
Een Dependency Dashboard-issue van Renovate in elke repository, voor de status in één oogopslag.
Het volledige configuratieschema van Renovate: elke optie op docs.renovatebot.com werkt ongewijzigd op fremforge. Je regels worden toegepast bovenop het platformbeleid.
Een botgebruiker per tenant, <org>-fremforge-bot-deps, beperkt tot alleen jouw organisatie; het token gaat nooit over tenantgrenzen heen. Beveiligingsfixes gebruikt dezelfde bot.
EU-soeverein: draait op T Cloud Public CCE, zonder SaaS van derden in het datapad.

Inschakelen

Open Beveiliging › Herstellen › Updates van afhankelijkheden (of Bouwen en uitrollen › Updates van afhankelijkheden) en ga naar Versie-updates.
Schakel gehoste Renovate in.
fremforge richt een botgebruiker per tenant in, <org>-fremforge-bot-deps, en geeft die schrijftoegang tot de repository’s van je organisatie.
De repository’s worden opgepakt door de volgende nachtelijke run, of meteen met Nu uitvoeren; pull requests volgen daarna het schema in je renovate.json.

Inschakelen geeft de organisatie ook de standaardinstellingen van Beveiligingsfixes: fix-pull-requests op klik, wachtend op review.

De botgebruiker wordt door fremforge beheerd. Je hoeft hem niet aan te maken, zijn inloggegevens niet te roteren en je geen zorgen te maken over verloren wachtwoorden. Het token wordt door het platform beheerd en automatisch geroteerd.

Uitschakelen

Beveiliging › Herstellen › Updates van afhankelijkheden → Versie-updates → schakel gehoste Renovate uit.
fremforge trekt het token van de bot direct in en verwijdert de bot uit je organisatie, tenzij Beveiligingsfixes op een automatische modus staat: dan blijft de bot bestaan, alleen voor beveiligingsfixes.
PR’s die Renovate al heeft geopend, blijven open. Voeg ze samen of sluit ze zoals elke andere PR.
De renovate.json van de organisatie blijft in je repository’s staan; fremforge komt er niet aan.

Opnieuw inschakelen richt een nieuwe bot in. De vorige botgebruikersnaam wordt geblokkeerd (niet hergebruikt), zodat de auditgeschiedenis schoon blijft.

Platformbeleid

Elke run begint bij het beleid van fremforge, en je renovate.json wordt daar bovenop toegepast.

Cadans. De repository’s van elke ingeschreven organisatie worden elke nacht in de wachtrij gezet voor een run (vanaf 02:30 UTC); een repository die in de afgelopen 4 uur heeft gedraaid, wordt overgeslagen. Een schedule in je renovate.json beperkt nog steeds wanneer routinematige pull requests worden geopend. Beveiligingsupdates (vulnerability alerts) negeren dat schema en de wachttijd voor de releaseleeftijd, en worden geopend door de eerste run nadat het advisory is gepubliceerd. Nu uitvoeren start een run buiten de cyclus.
Wachttijd voor de releaseleeftijd. Een routinematige update wordt pas voorgesteld zodra de nieuwe versie zo oud is als de releaseleeftijd van je organisatie (3 dagen, tenzij een eigenaar dat heeft gewijzigd), zodat een kwaadaardige of kapotte release die binnen enkele dagen wordt ingetrokken je nooit bereikt. Registers die geen releasedatum publiceren, krijgen geen wachttijd. Beveiligingsupdates slaan de wachttijd over, met één uitzondering voor npm: een fixversie die jonger is dan de releaseleeftijd wordt alleen aangeboden als de advisorygegevens van npm haar vermelden als fix voor de versie die jij hebt. Een fix die die gegevens niet vermelden, wacht net als een routinematige update.
De wachttijd geldt ook voor je lockfile. Renovate stelt een versie voor, en je pakketbeheerder resolvet daarna de lockfile, inclusief eventuele nieuwe transitieve afhankelijkheden. Voor npm, pnpm en Yarn 1 loopt die resolve via fremforges releaseleeftijdsweergave van het npm-register, zodat een verhoging van een bereik geen versie kan vastleggen die jonger is dan 3 dagen. De weergave houdt voor elke organisatie 3 dagen aan; bij een langere releaseleeftijd houdt de check hieronder de pull request vast totdat de lockfile oud genoeg is. Je eigen .npmrc wordt daarna nog steeds toegepast, dus je privéscopes en een eventuele eigen registry=-regel gaan voor. Yarn 2+ leest in plaats daarvan .yarnrc.yml en valt niet onder de weergave; de check hieronder houdt die PR’s nog steeds vast.
De check fremforge/release-age. Elke pull request krijgt deze check, en het is een verplichte check van de branchbescherming. Op een PR voor een afhankelijkheidsupdate blijft hij in afwachting, met de tekst “Waiting until …”, totdat elke versie die de lockfile resolvet zo oud is als je releaseleeftijd. Daarna wordt hij binnen enkele minuten vanzelf groen, zonder nieuwe push, en automatisch samenvoegen wacht erop. Een versie die een gereviewd advisory (van elke ernst) op je basisbranch als fix noemt, wacht in plaats daarvan 24 uur, net als een nieuwe afhankelijkheid die alleen door die fix is binnengekomen van dezelfde uitgevers (het security-fix-spoor). Een fix voor een bekend misbruikte kwetsbaarheid wordt niet vastgehouden. Op een PR die door een persoon is geopend, worden verse versies gemeld maar houden ze de PR niet vast. Zet je de scanner op off voor een organisatie of repository, dan verdwijnt de check binnen een uur uit de branchbescherming.
Automatisch samenvoegen. Patch-, pin- en digest-updates worden standaard automatisch samengevoegd bij groene CI. Minor-updates worden automatisch samengevoegd als je dat aanzet in de beleidsinstellingen. Major-updates wachten altijd op je goedkeuring in het Dependency Dashboard.
Pakketten met een grote impact. Ongeveer 30 pakketten voor authenticatie, cryptografie, databases, ORM’s en cloud-KMS (bijvoorbeeld jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) voegen een routinematige update nooit automatisch samen; de PR wacht op review. OpenID-bibliotheken mogen een patch automatisch samenvoegen, maar nooit een minor of major.
Beveiligingsupdates. Of de eigen beveiligings-PR’s van gehoste Renovate bij groene CI automatisch worden samengevoegd, is de instelling Wanneer fixes worden gemerged van Beveiligingsfixes: Samenvoegen als de checks slagen of Wachten op review (de standaard). Organisaties die de vroegere instelling Security updates voor automatisch samenvoegen aan hadden staan, wat de standaard was voor elke ingeschreven organisatie, zijn overgezet naar Samenvoegen als de checks slagen, dus voor hen veranderde er niets. Daarmee wordt een beveiligings-PR voor elk pakket automatisch samengevoegd, ook voor de pakketten met een grote impact: dat zijn juist de bibliotheken die je het snelst gepatcht wilt hebben. Zie Samenvoegen.
Samenvoegvenster. Een beheerder van de organisatie kan beperken wanneer Renovate-PR’s worden klaargezet om samen te voegen, als hele UTC-uren op gekozen weekdagen (merge_window in PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). Buiten het venster wordt geen Renovate-PR klaargezet, en klaarzettingen van de bot worden geannuleerd zodra het venster sluit; een klaarzetting door een persoon blijft staan. Een repository met een openstaand issue met het label release-freeze wordt nooit klaargezet.
Fixes voor bekend misbruikte kwetsbaarheden. Een beveiligingsupdate voor een CVE die in het wild wordt misbruikt (vermeld in de EU Vulnerability Database van ENISA of de Known Exploited Vulnerabilities-catalogus van CISA, dagelijks gecontroleerd) wordt vóór elke andere update in de run geopend, wordt niet tegengehouden door de PR-limieten, en krijgt het label known-exploited (als je repository dat label heeft) en een notitie in de PR-beschrijving. Hij wordt ook buiten het samenvoegvenster klaargezet, zodat hij wordt samengevoegd zodra zijn checks slagen. Alleen het venster wordt overgeslagen: een PR wordt er alleen buiten klaargezet als hij er binnen ook klaargezet zou zijn, en de releasefreeze, een persoon die het automatisch samenvoegen annuleert en je verplichte checks gelden allemaal nog.
Jouw regels winnen. Regels in je renovate.json worden na dit beleid toegepast, dus een regel automerge: true daar overschrijft het, inclusief het vasthouden voor review van pakketten met een grote impact. Voeg je zo’n regel toe, sluit die pakketten er dan van uit (zie het voorbeeld hieronder).

Instellingen

Een eigenaar stelt het beleid van het spoor in op de pagina, of met PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (scope dependency-updates:write). Elk veld is optioneel; een weggelaten veld houdt zijn waarde, en een onbekend veld wordt geweigerd met unknown-field.

Instelling	API-veld	Standaard
Gehoste Renovate draait	`enabled`	`true`
Patch-, pin- en digest-updates automatisch samenvoegen	`automerge_patch`	`true`
Minor-updates automatisch samenvoegen	`automerge_minor`	`false`
Major-updates vereisen goedkeuring in het Dependency Dashboard	`major_approval`	`true`
Schema overschrijven (schematekst van Renovate)	`schedule`	geen
Pull requests per uur	`pr_hourly_limit`	2
Gelijktijdig openstaande pull requests	`pr_concurrent_limit`	5
Samenvoegvenster	`merge_window`	geen

GET op hetzelfde pad geeft dezelfde velden terug, in dezelfde snake_case-spelling. security_automerge is hier geen veld: of beveiligings-PR’s zichzelf samenvoegen, is de instelling merge van Beveiligingsfixes, en security_automerge naar dit pad sturen wordt geweigerd met een melding die dat zegt.

Configureren

Configuratie per repository gaat via renovate.json in de root van de repository. Zonder dat bestand gebruikt Renovate verstandige standaarden, en dat is meestal prima voor de eerste maand, terwijl je ziet wat voor PR’s er binnenkomen.

Een minimale start:

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

Een configuratie met meer eigen keuzes, die OpenTelemetry-pakketten groepeert, patch- en lockfile-verhogingen automatisch samenvoegt en een menselijke review vereist voor major-verhogingen:

{
  "$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"]
    }
  ]
}

De automerge-regel in dit voorbeeld wordt na het platformbeleid toegepast, dus die zou ook de pakketten voor authenticatie, cryptografie en databases automatisch samenvoegen die fremforge anders voor review vasthoudt. Wil je die handmatig houden, sluit ze dan uit van de regel, bijvoorbeeld met "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

De volledige configuratiereferentie van Renovate staat op docs.renovatebot.com/configuration-options/.

Wat er wordt verhoogd

Renovate detecteert de meeste ecosystemen automatisch, zonder configuratie. Automatisch gedetecteerde ecosystemen op fremforge:

npm / pnpm / yarn: package.json + onderhoud van de lockfile
Go-modules: go.mod
OpenTofu / Terraform: providerversies in versions.tf
Dockerfile: FROM-regels, met de optie om op digest vast te pinnen
Helm: chartversies in values.yaml en Chart.yaml
Eigen regex-pins: voor elke versiestring in elk bestand (ideaal om binaries vast te pinnen die door shellscripts worden geïnstalleerd)
Python: pyproject.toml, requirements*.txt, Pipfile en Poetry. Met hashes vastgepinde requirements die zijn gecompileerd met uv pip compile of pip-compile worden als geheel opnieuw gelockt; zie Gecompileerde Python-requirements.

Voor de volledige matrix van ecosystemen, zie docs.renovatebot.com/modules/manager/.

Gecompileerde Python-requirements

Een requirements*.txt die is geschreven door uv pip compile of pip-compile pint elk pakket vast, vaak met --hash-regels. Sommige verhogingen vereisen ook dat een andere pin meeschuift. pydantic pint bijvoorbeeld pydantic-core vast op één exacte versie. Als de header van de lock het commando noemt dat hem heeft geschreven, voert gehoste Renovate dat commando opnieuw uit met --upgrade-package, zodat de pull request voor de update het hele opnieuw gelockte bestand bevat: het verhoogde pakket, elke pin die meeschuift, en hun hashes. Zonder het opnieuw locken wijzigt de PR één regel en weigert pip install --require-hashes hem.

Gehoste Renovate doet dit voor elke requirements*.txt waarvan de header een compile-commando bevat, in elke organisatie. Je hoeft niets te configureren, zolang de header de regels van Renovate volgt:

Gebruik lange optienamen, en koppel elke waarde met =, bijvoorbeeld --output-file=requirements.txt, --python-version=3.11, --extra=dev en --group=dev. uv schrijft het commando precies zo in de header als je het hebt getypt. Renovate weigert -o requirements.txt en --python-version 3.11, en laat die lock dan ongemoeid.
Noem het bronbestand, bijvoorbeeld uv pip compile pyproject.toml .... Een header zonder bronbestand (bijvoorbeeld uv pip compile --group render ...) wordt niet opnieuw gelockt.
Geef elke directe afhankelijkheid een versiebeperking. Een afhankelijkheid zonder enige versie ("httpx") wordt niet opnieuw gelockt; de verhoging ervan wijzigt alleen de eigen regel. Een ondergrens zoals "httpx>=0.28" is genoeg.

Een header die werkt:

# 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 houdt --python-version aan bij het opnieuw locken, dus stel die in op de oudste Python-versie die je ondersteunt. Het opnieuw gelockte bestand is hetzelfde bestand dat je eigen compile zou opleveren, en het legt geen index-URL vast.

Het opnieuw locken resolvet tegen het openbare PyPI, dezelfde index die Renovate gebruikt om de nieuwe versie te vinden, tenzij de header of je pyproject.toml een andere index noemt. Een met de hand geschreven requirements.txt zonder compile-header wordt zoals voorheen regel voor regel bijgewerkt.

Runs buiten de cyclus

Heb je een Renovate-run nodig vóór de volgende geplande cyclus (bijvoorbeeld omdat je net een nieuwe renovate.json hebt gepubliceerd en wilt zien wat die oplevert)?

Beveiliging › Herstellen › Updates van afhankelijkheden → Nu uitvoeren.
Beperkt tot één run buiten de cyclus per uur per organisatie.
De resultaten verschijnen binnen een paar minuten onder Activiteit.

PR’s naar aanleiding van kwetsbaarheden lopen al automatisch buiten de cyclus om. Je hoeft niet op “Nu uitvoeren” te klikken als er een nieuwe CVE verschijnt; de eigen kwetsbaarheidsplanner van Renovate handelt dat af.

Cadans aanpassen

Het veld schedule van Renovate accepteert expressies in cron-stijl. Een paar gangbare patronen:

["before 4am on the first day of the month"]: één keer per maand. (De standaard van fremforge is geen schema: elke nacht een run, en pull requests mogen bij elke run worden geopend.)
["before 4am every weekday"]: dagelijks op werkdagen.
["after 9pm and before 5am"]: alleen buiten kantoortijden.
[]: nooit; vertrouw alleen op runs naar aanleiding van kwetsbaarheden.

Het veld vulnerabilityAlerts.schedule overschrijft het schema voor beveiligings-PR’s:

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

Kosten

Inbegrepen in het abonnement van € 30 per gebruiker. Geen metering, geen kosten per PR, geen aparte post voor runnerminuten.

Ter vergelijking: Dependabot van GitHub is gratis, maar Dependabot Updates die op Actions draaien, verbruiken je Actions-minuten. De gehoste Renovate van fremforge draait op CCE-infrastructuur die fremforge beheert (los van je pool met CI-runners, dus hij verbruikt nooit runnerminuten). Dat is het praktische verschil.

Waarom Renovate en niet Dependabot

Renovate is de OSS-tool die we op onze eigen repository’s draaien, met dezelfde configuratie, dezelfde cadans en dezelfde vorm van PR’s, en die we hebben gekozen om als gehoste functie voor updates van afhankelijkheden aan te bieden. Renovate ondersteunt Forgejo native sinds v37; zijn configuratieschema is breder dan dat van Dependabot; hij werkt met eigen regex-pins, wat Dependabot niet doet. De meeste teams die beide gebruiken, geven de voorkeur aan Renovate.

Je kunt Renovate ook zelf hosten tegen je eigen fremforge-repository’s zonder je in te schrijven voor de gehoste versie. Zet gewoon een renovate.json neer en draai Renovate zelf in CI. De gehoste versie is de gemakslaag; de OSS-configuratie van Renovate die je schrijft, is in beide gevallen identiek.

Privéregisters

Voeg een leesreferentie toe onder Beveiliging › Herstellen › Updates van afhankelijkheden → Versie-updates → Privéregisters:

Label: een naam voor je eigen gebruik (bijvoorbeeld “GitHub Packages”).
Type: npm, docker of git (een privé-git-host voor het opzoeken van modules en tags, bijvoorbeeld een privébron voor Terraform-modules).
Host-/registry-URL: de host van het register (bijvoorbeeld npm.pkg.github.com) of een URL-prefix met https://. Loopback-, metadata- en privébereikhosts worden geweigerd.
Gebruikersnaam: alleen voor Docker-basic-auth; laat leeg voor npm en git met alleen een token.
Token / wachtwoord: een token met alleen leesrechten voor dat register.

Het token wordt versleuteld opgeslagen (AES-256-GCM), wordt alleen gebruikt voor je eigen Renovate-runs, wordt nooit door de API teruggegeven en wordt, anders dan een Actions-secret, nooit blootgesteld aan je CI-workflows. Renovate authenticeert bij dat register vanaf de volgende run. Je kunt een referentie altijd verwijderen; het opzoeken van de pakketten ervan mislukt dan weer totdat je hem opnieuw toevoegt.

Dit is de fremforge-tegenhanger van de registry-secrets van Dependabot van GitHub.

Kruisverwijzingen

Renovate-documentatie (upstream): de volledige configuratiereferentie.
Beveiliging en supply chain: hoe Renovate past in het bredere verhaal over de supply chain.
Beveiligingsfixes: het andere spoor, één pull request per kwetsbaar pakket.
Probleemoplossing: als PR’s niet worden geopend of een run mislukt.
Webhooks: de PR’s van Renovate vuren dezelfde pull_request-webhookgebeurtenissen af als elke andere PR.

Transitieve afhankelijkheden Samenvoegen