Versionsuppdateringar

Versionsuppdateringar är spåret med hostad Renovate i Uppdateringar av beroenden. Aktivera det för en organisation så öppnar fremforge grupperade PR:er som går att granska, enligt det schema som din renovate.json anger: npm, gomod, Terraform-providers, bas-images i Dockerfiles, Helm-charts och alla egna regex-låsningar. Alla anslutna organisationers repon körs varje natt; se Intervall.

Sårbara beroenden som dina skanningar hittar är det andra spårets uppgift: Säkerhetsfixar öppnar en pull request per sårbart paket. Tills spåret Säkerhetsfixar tar över för din organisation öppnar hostad Renovate även egna säkerhets-pull requests för säkerhetsmeddelanden i OSV, enligt beskrivningen nedan.

Ingår i planen för 30 € per användare. Ingen tilläggsnivå, inga action-minuter hos tredje part, inget GitHub-företaget i datavägen.

Vad du får

Automatiska PR:er för inaktuella beroenden, förnuftigt grupperade, en PR per uppsättning relaterade paket i stället för dussintals enradiga uppgraderingar.
PR:er som utlöses av sårbarheter för publicerade säkerhetsmeddelanden (OSV), som öppnas vid nästa körning i stället för att vänta på ditt schema och som inte hålls tillbaka av väntetiden för versionsålder som beskrivs under Plattformspolicy (för npm, se det enda undantaget där). När spåret Säkerhetsfixar tar över för en organisation stängs de av där, så att en fix bara föreslås en gång.
En Renovate Dependency Dashboard-issue i varje repo, så att du ser status i en överblick.
Hela Renovates konfigurationsschema, alla alternativ på docs.renovatebot.com fungerar oförändrade på fremforge. Dina regler tillämpas ovanpå plattformspolicyn.
En botanvändare per tenant, <org>-fremforge-bot-deps, avgränsad till bara din organisation; token passerar aldrig gränser mellan tenants. Säkerhetsfixar använder samma bot.
EU-suveränt, körs på T Cloud Public CCE; ingen SaaS från tredje part i datavägen.

Aktivera

Öppna Säkerhet › Åtgärda › Uppdateringar av beroenden (eller Bygg och driftsätt › Uppdateringar av beroenden) och gå till Versionsuppdateringar.
Aktivera hostad Renovate.
fremforge skapar en botanvändare per tenant, <org>-fremforge-bot-deps, och ger den skrivåtkomst till organisationens repon.
Repona plockas upp av nästa nattliga körning, eller direkt med Kör nu; pull requests följer sedan schemat i din renovate.json.

När du aktiverar får organisationen också standardinställningarna för Säkerhetsfixar: fix-pull requests vid klick, som väntar på granskning.

Botanvändaren hanteras av fremforge. Du behöver inte skapa den, rotera dess inloggningsuppgifter eller oroa dig för bortglömda lösenord. Token hanteras av plattformen och roteras automatiskt.

Inaktivera

Säkerhet › Åtgärda › Uppdateringar av beroenden → Versionsuppdateringar → inaktivera hostad Renovate.
fremforge återkallar botens token direkt och tar bort boten från din organisation, om inte Säkerhetsfixar är inställt på ett automatiskt läge: då finns boten kvar, bara för säkerhetsfixar.
PR:er som Renovate redan har öppnat förblir öppna. Merga eller stäng dem som vilken annan PR som helst.
Organisationens renovate.json finns kvar i dina repon; fremforge rör den inte.

Om du aktiverar igen skapas en ny bot. Den tidigare botens användarnamn spärras (återanvänds inte) så att granskningshistoriken förblir ren.

Plattformspolicy

Varje körning utgår från fremforges policy, och din renovate.json tillämpas ovanpå den.

Intervall. Alla anslutna organisationers repon köas för en körning varje natt (från 02.30 UTC); ett repo som har körts under de senaste 4 timmarna hoppas över. Ett schedule i din renovate.json begränsar fortfarande när rutinmässiga pull requests öppnas. Säkerhetsuppdateringar (sårbarhetsvarningar) bortser från det schemat och från väntetiden för versionsålder, och öppnas vid nästa körning efter att säkerhetsmeddelandet har publicerats. Kör nu startar en körning utanför schemat.
Väntetid för versionsålder. En rutinuppdatering föreslås först när den nya versionen är lika gammal som organisationens versionsålder (3 dagar om inte en ägare har ändrat den), så att en skadlig eller trasig version som dras tillbaka inom några dagar aldrig når dig. Register som inte publicerar något släppdatum får ingen väntetid. Säkerhetsuppdateringar hoppar över väntetiden, med ett undantag för npm: en fixversion som är yngre än versionsåldern erbjuds bara när npm:s data om säkerhetsmeddelanden listar den som en fix för den version du har. En fix som den datan inte listar väntar som en rutinuppdatering.
Väntetiden täcker även din låsfil. Renovate föreslår en version, och din pakethanterare löser sedan upp låsfilen, inklusive nya transitiva beroenden. För npm, pnpm och Yarn 1 går den upplösningen genom fremforges vy av npm-registret med versionsålder, så att en höjning av ett intervall inte kan låsa en version som är yngre än 3 dagar. Vyn håller 3 dagar för alla organisationer; med en längre versionsålder håller kontrollen nedan kvar pull requesten tills låsfilen är tillräckligt gammal. Din egen .npmrc tillämpas fortfarande efter den, så dina privata scopes och en eventuell egen rad registry= har företräde. Yarn 2+ läser i stället .yarnrc.yml och täcks inte av vyn; kontrollen nedan håller fortfarande kvar de PR:erna.
Kontrollen fremforge/release-age. Varje pull request får den här kontrollen, och den är en obligatorisk kontroll i branch-skyddet. På en PR med beroendeuppdateringar förblir den väntande, med texten “Waiting until …”, tills varje version som låsfilen löser upp är lika gammal som din versionsålder. Den blir sedan grön av sig själv inom några minuter, utan en ny push, och automatisk merge väntar på den. En version som ett granskat säkerhetsmeddelande (vilken allvarlighetsgrad som helst) på din bas-branch anger som sin fix väntar i stället 24 timmar, och detsamma gäller ett nytt beroende som bara den fixen drog in från samma utgivare (spåret för säkerhetsfixar). En fix för en känd utnyttjad sårbarhet hålls inte kvar. På en PR som en person har öppnat rapporteras nya versioner men håller inte kvar PR:en. Om skannern sätts till off för en organisation eller ett repo tas kontrollen bort från branch-skyddet inom en timme.
Automatisk merge. Uppdateringar av patch, pin och digest mergas automatiskt vid grön CI som standard. Minor-uppdateringar mergas automatiskt om du slår på det i policyinställningarna. Major-uppdateringar väntar alltid på ditt godkännande på Dependency Dashboard.
Paket med stor påverkan. Ett trettiotal paket för autentisering, kryptografi, databaser, ORM och moln-KMS (till exempel jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) mergar aldrig en rutinuppdatering automatiskt; PR:en väntar på granskning. OpenID-bibliotek får automatiskt merga en patch men aldrig en minor eller major.
Säkerhetsuppdateringar. Om hostad Renovates egna säkerhets-PR:er mergas automatiskt vid grön CI styrs av inställningen När fixar mergas under Säkerhetsfixar: Sammanfoga när kontrollerna går igenom eller Vänta på granskning (standard). Organisationer som hade den tidigare automatiska mergen för Security updates påslagen, vilket var standard för alla anslutna organisationer, flyttades till Sammanfoga när kontrollerna går igenom, så inget ändrades för dem. Med den mergas en säkerhets-PR automatiskt för alla paket, även de med stor påverkan: det är de bibliotek du helst vill få patchade snabbt. Se Merge.
Merge-fönster. En administratör i organisationen kan begränsa när Renovate-PR:er armeras för merge, till hela UTC-timmar på valda veckodagar (merge_window i PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). Utanför fönstret armeras ingen Renovate-PR, och armeringar som boten gjort avbryts när fönstret stängs; en armering som en person gjort lämnas orörd. Ett repo med en öppen issue märkt release-freeze armeras aldrig.
Fixar för kända utnyttjade sårbarheter. En säkerhetsuppdatering för en CVE som utnyttjas i praktiken (listad i ENISA:s EU Vulnerability Database eller CISA:s katalog Known Exploited Vulnerabilities, kontrolleras dagligen) öppnas före alla andra uppdateringar i körningen, hålls inte tillbaka av gränserna för PR:er, och får etiketten known-exploited (när ditt repo har den etiketten) och en notering i PR-beskrivningen. Den armeras också utanför merge-fönstret, så den mergas så snart dess kontroller går igenom. Bara fönstret hoppas över: en PR armeras utanför det bara om den skulle ha armerats inom det, och release-frysningen, en person som avbryter den automatiska mergen och dina obligatoriska kontroller gäller fortfarande.
Dina regler vinner. Reglerna i din renovate.json tillämpas efter den här policyn, så en regel med automerge: true där åsidosätter den, inklusive granskningsspärren för paket med stor påverkan. Om du lägger till en sådan regel, undanta de paketen från den (se exemplet nedan).

Inställningar

En ägare anger spårets policy på sidan, eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (scope dependency-updates:write). Alla fält är valfria; ett fält som utelämnas behåller sitt värde, och ett okänt fält avvisas med unknown-field.

Inställning	API-fält	Standard
Hostad Renovate körs	`enabled`	`true`
Automatisk merge av patch-, pin- och digest-uppdateringar	`automerge_patch`	`true`
Automatisk merge av minor-uppdateringar	`automerge_minor`	`false`
Major-uppdateringar kräver godkännande på Dependency Dashboard	`major_approval`	`true`
Åsidosatt schema (schematext för Renovate)	`schedule`	inget
Pull requests per timme	`pr_hourly_limit`	2
Öppna pull requests samtidigt	`pr_concurrent_limit`	5
Merge-fönster	`merge_window`	inget

GET på samma sökväg returnerar samma fält, med samma snake_case-stavning. security_automerge är inget fält här: om säkerhets-PR:er mergas av sig själva styrs av inställningen merge under Säkerhetsfixar, och om du skickar security_automerge till den här sökvägen avvisas det med ett meddelande som säger det.

Konfigurera

Konfiguration per repo görs med renovate.json i repots rot. Utan den använder Renovate förnuftiga standardvärden, vilket oftast räcker den första månaden medan du ser vilka sorters PR:er som kommer in.

En minimal start:

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

En mer bestämd konfiguration som grupperar OpenTelemetry-paket, mergar patch- och låsfilsuppdateringar automatiskt och kräver mänsklig granskning för major-uppdateringar:

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

Regeln automerge i det här exemplet tillämpas efter plattformspolicyn, så den skulle också automatiskt merga de paket för autentisering, kryptografi och databaser som fremforge annars håller kvar för granskning. För att behålla dem manuella, undanta dem från regeln, till exempel "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

Den fullständiga referensen för Renovates konfiguration finns på docs.renovatebot.com/configuration-options/.

Vad som uppdateras

Renovate upptäcker de flesta ekosystem automatiskt utan konfiguration. Ekosystem som upptäcks automatiskt på fremforge:

npm / pnpm / yarn, package.json + underhåll av låsfiler
Go-moduler, go.mod
OpenTofu / Terraform, providerversioner i versions.tf
Dockerfile, rader med FROM, med möjlighet att låsa digest
Helm, chartversioner i values.yaml och Chart.yaml
Egna regex-låsningar, för vilken versionssträng som helst i vilken fil som helst (utmärkt för att låsa binärer som installeras med skalskript)
Python, pyproject.toml, requirements*.txt, Pipfile och Poetry. Hashlåsta requirements som kompilerats med uv pip compile eller pip-compile låses om i sin helhet; se Kompilerade Python-requirements.

Den fullständiga matrisen över ekosystem finns på docs.renovatebot.com/modules/manager/.

Kompilerade Python-requirements

En requirements*.txt som skrivits av uv pip compile eller pip-compile låser varje paket, ofta med rader med --hash. Vissa uppgraderingar kräver också att en annan låsning flyttas. Till exempel låser pydantic pydantic-core till en exakt version. När låsfilens huvud anger det kommando som skrev den kör hostad Renovate det kommandot igen med --upgrade-package, så att pull requesten med uppdateringen innehåller hela den omlåsta filen: det uppgraderade paketet, varje låsning det flyttar och deras hashar. Utan omlåsningen ändrar PR:en en rad och pip install --require-hashes avvisar den.

Hostad Renovate gör detta för varje requirements*.txt vars huvud innehåller ett kompileringskommando, i alla organisationer. Du behöver inte konfigurera något, så länge huvudet följer Renovates regler:

Använd långa alternativnamn, och koppla varje värde med =, till exempel --output-file=requirements.txt, --python-version=3.11, --extra=dev och --group=dev. uv skriver kommandot i huvudet exakt som du skrev det. Renovate avvisar -o requirements.txt och --python-version 3.11, och lämnar då den låsfilen orörd.
Ange källfilen, till exempel uv pip compile pyproject.toml .... Ett huvud utan källfil (till exempel uv pip compile --group render ...) låses inte om.
Ge varje direkt beroende ett versionsvillkor. Ett beroende som skrivits utan någon version alls ("httpx") låses inte om; dess uppgradering ändrar bara dess egen rad. En undre gräns som "httpx>=0.28" räcker.

Ett huvud som fungerar:

# 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åller --python-version när den låser om, så sätt den till den äldsta Python-version du stöder. Den omlåsta filen är samma fil som din egen kompilering skulle ge, och den registrerar ingen index-URL.

Omlåsningen löser upp mot publika PyPI, samma index som Renovate använder för att hitta den nya versionen, om inte huvudet eller din pyproject.toml anger ett annat index. En handskriven requirements.txt utan kompileringshuvud uppdateras en rad i taget, som tidigare.

Körningar utanför schemat

Behöver du en Renovate-körning före nästa schemalagda omgång (t.ex. för att du just publicerat en ny renovate.json och vill se vad den ger)?

Säkerhet › Åtgärda › Uppdateringar av beroenden → Kör nu.
Begränsat till en körning utanför schemat per timme och organisation.
Resultaten visas under Aktivitet inom några minuter.

PR:er som utlöses av sårbarheter körs redan utanför schemat automatiskt. Du behöver inte klicka på “Kör nu” när en ny CVE dyker upp; Renovates egen schemaläggare för sårbarheter hanterar det.

Anpassa intervallet

Renovates fält schedule tar emot uttryck i cron-stil. Några vanliga mönster:

["before 4am on the first day of the month"], en gång i månaden. (fremforges standard är inget schema: en körning varje natt, och pull requests kan öppnas vid vilken körning som helst.)
["before 4am every weekday"], dagligen på vardagar.
["after 9pm and before 5am"], bara utanför kontorstid.
[], aldrig; förlita dig bara på körningar som utlöses av sårbarheter.

Fältet vulnerabilityAlerts.schedule åsidosätter för säkerhets-PR:er:

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

Kostnad

Ingår i planen för 30 € per användare. Ingen mätning, ingen avgift per PR, ingen separat rad för runner-minuter.

Som jämförelse: GitHubs Dependabot är gratis, men Dependabot-uppdateringar som körs på Actions förbrukar dina Actions-minuter. fremforges hostade Renovate körs på CCE-infrastruktur som fremforge hanterar (skild från din pool av CI-runners, så den förbrukar aldrig runner-minuter). Det är den praktiska skillnaden.

Varför Renovate och inte Dependabot

Renovate är det verktyg med öppen källkod som vi kör mot våra egna repon, med samma konfiguration, samma intervall och samma form på PR:erna, och som vi valde att exponera som den hostade funktionen för beroendeuppdateringar. Renovate har haft inbyggt stöd för Forgejo sedan v37; dess konfigurationsschema är bredare än Dependabots; det fungerar med egna regex-låsningar, vilket Dependabot inte gör. De flesta team som använder båda föredrar Renovate.

Du kan också själv hosta Renovate mot dina egna repon på fremforge utan att ansluta dig till den hostade versionen. Lägg bara in en renovate.json och kör Renovate själv i CI. Den hostade versionen är bekvämlighetslagret; den Renovate-konfiguration du skriver är identisk i båda fallen.

Privata register

Lägg till en läsbehörighet under Säkerhet › Åtgärda › Uppdateringar av beroenden → Versionsuppdateringar → Privata register:

Etikett: ett namn för din egen skull (t.ex. “GitHub Packages”).
Typ: npm, docker eller git (en privat git-värd för uppslag av moduler och taggar, t.ex. en privat källa för Terraform-moduler).
Värd-/registry-URL: registrets värd (t.ex. npm.pkg.github.com) eller ett URL-prefix med https://. Loopback-, metadata- och privata adresser avvisas.
Användarnamn: bara för basic-auth mot Docker; lämna tomt för npm och git med bara token.
Token/lösenord: en token med bara läsbehörighet för det registret.

Token lagras krypterad (AES-256-GCM), används bara för dina egna Renovate-körningar, returneras aldrig av API:t och exponeras, till skillnad från en Actions-hemlighet, aldrig för dina CI-arbetsflöden. Renovate autentiserar mot registret vid nästa körning. Ta bort en inloggningsuppgift när som helst; uppslag för dess paket börjar då misslyckas igen tills du lägger till den på nytt.

Det här är fremforges motsvarighet till GitHubs registerhemligheter för Dependabot.

Korsreferenser

Renovates dokumentation (uppströms), fullständig konfigurationsreferens.
Säkerhet och leveranskedja, hur Renovate passar in i den större berättelsen om leveranskedjan.
Säkerhetsfixar, det andra spåret: en pull request per sårbart paket.
Felsökning, när PR:er inte öppnas eller en körning misslyckas.
Webhooks, Renovates PR:er utlöser samma webhook-händelser pull_request som alla andra PR:er.

Transitiva beroenden Merge