Versionsopdateringer

Versionsopdateringer er sporet med hostet Renovate under Opdateringer af afhængigheder. Slå det til for en organisation, så åbner fremforge grupperede pull requests, der er lette at gennemgå, efter den tidsplan, din renovate.json angiver: npm, gomod, Terraform-providers, base-images i Dockerfiles, Helm-charts og enhver brugerdefineret regex-fastlåsning. Alle tilmeldte organisationers repositorier køres hver nat; se Hyppighed.

Sårbare afhængigheder, som dine scanninger finder, er det andet spors opgave: Sikkerhedsrettelser åbner én pull request pr. sårbar pakke. Indtil sporet Sikkerhedsrettelser overtager for din organisation, åbner hostet Renovate også sine egne sikkerheds-pull requests for OSV-advisories, som beskrevet nedenfor.

Indbygget i planen til 30 € pr. bruger. Ingen tillægspakke, ingen action-minutter hos tredjeparter, ingen GitHub-virksomheden i datavejen.

Hvad du får

• Automatiske pull requests for forældede afhængigheder, fornuftigt grupperet, én pull request pr. sæt af beslægtede pakker i stedet for dusinvis af enlinjede opdateringer.
• Pull requests udløst af sårbarheder for offentliggjorte sikkerhedsadvisories (OSV), åbnet af den næste kørsel i stedet for at vente på din tidsplan og ikke holdt tilbage af ventetiden for udgivelsesalder, der er beskrevet under Platformens politik (for npm, se den ene undtagelse der). Når sporet Sikkerhedsrettelser overtager for en organisation, slås de fra der, så en rettelse kun foreslås én gang.
• Et Renovate Dependency Dashboard-issue i hvert repo, så du kan se status med ét blik.
• Renovates fulde konfigurationsskema, alle muligheder på docs.renovatebot.com virker uændret på fremforge. Dine regler anvendes oven på platformens politik.
• En bot-bruger pr. tenant, <org>-fremforge-bot-deps, begrænset til din organisation; tokenet krydser aldrig tenant-grænser. Sikkerhedsrettelser bruger den samme bot.
• EU-suveræn, kører på T Cloud Public CCE; ingen SaaS fra tredjeparter i datavejen.

Sådan slår du det til

1. Åbn Sikkerhed › Ret › Opdateringer af afhængigheder (eller Byg og udrul › Opdateringer af afhængigheder), og gå til Versionsopdateringer.
2. Slå hostet Renovate til.
3. fremforge opretter en bot-bruger pr. tenant, <org>-fremforge-bot-deps, og giver den skriveadgang til din organisations repositorier.
4. Repositorierne tages med i den næste natlige kørsel eller straks med Kør nu; derefter følger pull requests tidsplanen i din renovate.json.

Når du slår det til, får organisationen også standardindstillingerne for Sikkerhedsrettelser: rettelses-pull requests ved klik, der venter på gennemgang.

Bot-brugeren administreres af fremforge. Du behøver ikke oprette den, rotere dens credentials eller bekymre dig om mistede adgangskoder. Tokenet administreres af platformen og roteres automatisk.

Sådan slår du det fra

1. Sikkerhed › Ret › Opdateringer af afhængigheder → Versionsopdateringer → slå hostet Renovate fra.
2. fremforge tilbagekalder straks bottens token og fjerner botten fra din organisation, medmindre Sikkerhedsrettelser er sat til en automatisk tilstand: så bliver botten, kun til sikkerhedsrettelser.
3. Pull requests, som Renovate allerede har åbnet, forbliver åbne. Merge eller luk dem, som du ville gøre med enhver anden pull request.
4. Organisationens renovate.json bliver i dine repositorier; fremforge rører den ikke.

Når du slår det til igen, oprettes en ny bot. Det tidligere botbrugernavn bliver spærret (ikke genbrugt), så revisionshistorikken forbliver ren.

Platformens politik

Hver kørsel tager udgangspunkt i fremforges politik, og din renovate.json anvendes oven på den.

• Hyppighed. Alle tilmeldte organisationers repositorier sættes i kø til en kørsel hver nat (fra 02:30 UTC); et repository, der er kørt inden for de seneste 4 timer, springes over. En schedule i din renovate.json begrænser stadig, hvornår rutinemæssige pull requests åbnes. Sikkerhedsopdateringer (vulnerability alerts) ignorerer den tidsplan og ventetiden for udgivelsesalder og åbnes af den næste kørsel, efter at advisoryen er offentliggjort. Kør nu starter en kørsel uden for cyklussen.
• Ventetid for udgivelsesalder. En rutinemæssig opdatering foreslås først, når den nye version er lige så gammel som din organisations udgivelsesalder (3 dage, medmindre en ejer har ændret den), så en ondsindet eller defekt udgivelse, der trækkes tilbage inden for få dage, aldrig når frem til dig. Registries, der ikke offentliggør en udgivelsesdato, får ingen ventetid. Sikkerhedsopdateringer springer ventetiden over, med én undtagelse for npm: en rettelsesversion, der er yngre end udgivelsesalderen, tilbydes kun, når npm’s advisory-data angiver, at den retter den version, du har. En rettelse, som de data ikke angiver, venter som en rutinemæssig opdatering.
• Ventetiden dækker også din lockfil. Renovate foreslår en version, og din pakkehåndtering opløser derefter lockfilen, inklusive eventuelle nye transitive afhængigheder. For npm, pnpm og Yarn 1 går den opløsning gennem fremforges udgivelsesalder-visning af npm-registret, så en udvidelse af et interval ikke kan låse en version, der er yngre end 3 dage. Visningen holder 3 dage for alle organisationer; med en længere udgivelsesalder holder tjekket nedenfor pull requesten tilbage, indtil lockfilen er gammel nok. Din egen .npmrc anvendes stadig bagefter, så dine private scopes og en eventuel registry=-linje fra dig har forrang. Yarn 2+ læser i stedet .yarnrc.yml og er ikke dækket af visningen; tjekket nedenfor holder stadig de pull requests tilbage.
• Tjekket fremforge/release-age. Hver pull request får dette tjek, og det er et påkrævet tjek i branch-beskyttelsen. På en pull request med opdateringer af afhængigheder forbliver det afventende med teksten “Waiting until …”, indtil hver version, lockfilen opløser til, er lige så gammel som din udgivelsesalder. Derefter bliver det selv grønt inden for få minutter uden et nyt push, og auto-merge venter på det. En version, som en gennemgået advisory (uanset alvorlighed) på din base-branch nævner som sin rettelse, venter i stedet 24 timer, og det samme gør en ny afhængighed, som kun den rettelse har trukket ind fra de samme udgivere (sporet for sikkerhedsrettelser). En rettelse af en kendt udnyttet sårbarhed holdes ikke tilbage. På en pull request åbnet af en person rapporteres nye versioner, men de holder ikke pull requesten tilbage. Sætter du scanneren til off for en organisation eller et repo, fjernes tjekket fra branch-beskyttelsen inden for en time.
• Auto-merge. Opdateringer af patch, pin og digest auto-merges som standard, når CI er grøn. Minor-opdateringer auto-merges, hvis du slår det til i politikindstillingerne. Major-opdateringer venter altid på din godkendelse i Dependency Dashboard.
• Pakker med stor skadesradius. Omkring 30 pakker til godkendelse, kryptografi, databaser, ORM og cloud-KMS (for eksempel jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) auto-merger aldrig en rutinemæssig opdatering; pull requesten venter på gennemgang. OpenID-biblioteker kan auto-merge en patch, men aldrig en minor eller major.
• Sikkerhedsopdateringer. Om hostet Renovates egne sikkerheds-pull requests auto-merges, når CI er grøn, styres af indstillingen Hvornår rettelser merges under Sikkerhedsrettelser: Flet, når tjek består eller Vent på gennemgang (standard). Organisationer, der havde den tidligere auto-merge af Security updates slået til, hvilket var standard for alle tilmeldte organisationer, blev flyttet til Flet, når tjek består, så for dem ændrede intet sig. Med den indstilling auto-merges en sikkerheds-pull request for alle pakker, også dem med stor skadesradius: det er netop de biblioteker, du helst vil have rettet hurtigt. Se Merging.
• Merge-vindue. En organisationsadministrator kan begrænse, hvornår Renovate-pull requests gøres klar til merge, i hele UTC-timer på valgte ugedage (merge_window i PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). Uden for vinduet gøres ingen Renovate-pull request klar, og de klargøringer, botten har lavet, annulleres, når vinduet lukker; en klargøring, som en person har lavet, lades i fred. Et repository med et åbent issue med etiketten release-freeze gøres aldrig klar.
• Rettelser af kendt udnyttede sårbarheder. En sikkerhedsopdatering for en CVE, der udnyttes i praksis (opført i ENISA’s EU Vulnerability Database eller CISA’s Known Exploited Vulnerabilities-katalog, tjekket dagligt), åbnes før alle andre opdateringer i kørslen, holdes ikke tilbage af grænserne for pull requests og får etiketten known-exploited (når dit repository har den etiket) og en note i pull requestens beskrivelse. Den gøres også klar uden for merge-vinduet, så den merges, så snart dens tjek består. Kun vinduet springes over: en pull request gøres kun klar uden for vinduet, hvis den ville være gjort klar inden for det, og release-frysningen, en person, der annullerer auto-merge, og dine påkrævede tjek gælder stadig.
• Dine regler vinder. Regler i din renovate.json anvendes efter denne politik, så en automerge: true-regel der tilsidesætter den, inklusive kravet om gennemgang af pakker med stor skadesradius. Tilføjer du sådan en regel, så udelad de pakker fra den (se eksemplet nedenfor).

Indstillinger

En ejer angiver sporets politik på siden eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (scope dependency-updates:write). Alle felter er valgfrie; et felt, der udelades, beholder sin værdi, og et ukendt felt afvises med unknown-field.

GET på den samme sti returnerer de samme felter med den samme snake_case-stavemåde. security_automerge er ikke et felt her: om sikkerheds-pull requests merger sig selv, er indstillingen merge under Sikkerhedsrettelser, og sender du security_automerge til denne sti, afvises det med en besked, der siger det.

Konfiguration

Konfiguration pr. repo sker via renovate.json i repoets rod. Uden den bruger Renovate fornuftige standarder, hvilket som regel er fint den første måned, mens du ser, hvilke slags pull requests der kommer.

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 mere holdningspræget konfiguration, der grupperer OpenTelemetry-pakker, auto-merger opdateringer af patch og lockfil og kræver menneskelig gennemgang af major-opdateringer:

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

automerge-reglen i dette eksempel anvendes efter platformens politik, så den ville også auto-merge de pakker til godkendelse, kryptografi og databaser, som fremforge ellers holder tilbage til gennemgang. For at beholde dem manuelle skal du udelade dem fra reglen, for eksempel "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

Den fulde reference for Renovates konfiguration findes på docs.renovatebot.com/configuration-options/.

Hvad der opdateres

Renovate finder selv de fleste økosystemer uden konfiguration. Automatisk fundne økosystemer på fremforge:

• npm / pnpm / yarn, package.json + vedligeholdelse af lockfil
• Go-moduler, go.mod
• OpenTofu / Terraform, providerversioner i versions.tf
• Dockerfile, FROM-linjer, med mulighed for fastlåsning med digest
• Helm, chartversioner i values.yaml og Chart.yaml
• Brugerdefinerede regex-fastlåsninger, for enhver versionsstreng i enhver fil (godt til at fastlåse binære filer installeret af shell-scripts)
• Python, pyproject.toml, requirements*.txt, Pipfile og Poetry. Hash-fastlåste requirements kompileret med uv pip compile eller pip-compile genlåses som helhed; se Kompilerede Python-requirements.

Den fulde oversigt over økosystemer står på docs.renovatebot.com/modules/manager/.

Kompilerede Python-requirements

En requirements*.txt skrevet af uv pip compile eller pip-compile fastlåser hver pakke, ofte med --hash-linjer. Nogle opdateringer kræver også, at en anden fastlåsning flytter sig. For eksempel fastlåser pydantic pydantic-core til én præcis version. Når lockfilens header nævner den kommando, der skrev den, kører hostet Renovate den kommando igen med --upgrade-package, så opdateringens pull request indeholder hele den genlåste fil: den opdaterede pakke, hver fastlåsning, den flytter, og deres hashes. Uden genlåsningen ændrer pull requesten én linje, og pip install --require-hashes afviser den.

Hostet Renovate gør det for enhver requirements*.txt, hvis header indeholder en kompileringskommando, i alle organisationer. Du behøver ikke konfigurere noget, så længe headeren følger Renovates regler:

• Brug lange optionsnavne, og forbind hver værdi med =, for eksempel --output-file=requirements.txt, --python-version=3.11, --extra=dev og --group=dev. uv skriver kommandoen ind i headeren præcis, som du skrev den. Renovate afviser -o requirements.txt og --python-version 3.11 og lader så den lockfil være.
• Angiv kildefilen, for eksempel uv pip compile pyproject.toml .... En header uden kildefil (for eksempel uv pip compile --group render ...) genlåses ikke.
• Giv hver direkte afhængighed et versionskrav. En afhængighed skrevet helt uden version ("httpx") genlåses ikke; dens opdatering ændrer kun dens egen linje. En nedre grænse som "httpx>=0.28" er nok.

En header, der virker:

# 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 beholder --python-version, når den genlåser, så sæt den til den ældste Python, du understøtter. Den genlåste fil er den samme fil, din egen kompilering ville give, og den registrerer ingen index-URL.

Genlåsningen opløser mod det offentlige PyPI, det samme index, som Renovate bruger til at finde den nye version, medmindre headeren eller din pyproject.toml nævner et andet index. En håndskrevet requirements.txt uden kompileringsheader opdateres én linje ad gangen som hidtil.

Kørsler uden for cyklussen

Har du brug for en Renovate-kørsel før den næste planlagte cyklus (for eksempel fordi du lige har udgivet en ny renovate.json og vil se, hvad den giver)?

1. Sikkerhed › Ret › Opdateringer af afhængigheder → Kør nu.
2. Begrænset til én kørsel uden for cyklussen pr. time pr. organisation.
3. Resultaterne vises under Aktivitet inden for få minutter.

Pull requests udløst af sårbarheder kører allerede automatisk uden for cyklussen. Du behøver ikke klikke på “Kør nu”, når en ny CVE dukker op; Renovates egen planlægning af sårbarheder tager sig af det.

Tilpasning af hyppighed

Renovates felt schedule accepterer cron-lignende udtryk. Nogle almindelige mønstre:

• ["before 4am on the first day of the month"], én gang om måneden. (fremforges standard er ingen tidsplan: en kørsel hver nat, og pull requests kan åbnes ved enhver kørsel.)
• ["before 4am every weekday"], dagligt på hverdage.
• ["after 9pm and before 5am"], kun uden for arbejdstid.
• [], aldrig; brug kun kørsler udløst af sårbarheder.

Feltet vulnerabilityAlerts.schedule tilsidesætter for sikkerheds-pull requests:

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

Pris

Inkluderet i planen til 30 € pr. bruger. Ingen måling, ingen betaling pr. pull request, ingen separat linje for runner-minutter.

Til sammenligning: GitHubs Dependabot er gratis, men Dependabot Updates, der kører på Actions, bruger dine Actions-minutter. fremforges hostede Renovate kører på CCE-infrastruktur, som fremforge administrerer (adskilt fra din pulje af CI-runners, så den bruger aldrig runner-minutter). Det er den praktiske forskel.

Hvorfor Renovate og ikke Dependabot

Renovate er det OSS-værktøj, vi kører mod vores egne repositorier, med samme konfiguration, samme hyppighed og samme slags pull requests, og som vi valgte at stille til rådighed som den hostede funktion til opdateringer af afhængigheder. Renovate har haft indbygget Forgejo-understøttelse siden v37; dets konfigurationsskema er bredere end Dependabots; det virker med brugerdefinerede regex-fastlåsninger, hvilket Dependabot ikke gør. De fleste teams, der bruger begge, foretrækker Renovate.

Du kan også selv hoste Renovate mod dine egne fremforge-repositorier uden at tilmelde dig den hostede version. Læg blot en renovate.json, og kør Renovate selv i CI. Den hostede version er bekvemmelighedslaget; den OSS-Renovate-konfiguration, du skriver, er den samme i begge tilfælde.

Private registre

Tilføj et læse-credential under Sikkerhed › Ret › Opdateringer af afhængigheder → Versionsopdateringer → Private registre:

1. Etiket: et navn til din egen reference (for eksempel “GitHub Packages”).
2. Type: npm, docker eller git (en privat git-vært til opslag af moduler/tags, for eksempel en privat kilde til Terraform-moduler).
3. Vært/registry-URL: registrets vært (for eksempel npm.pkg.github.com) eller et https://-URL-præfiks. Loopback-, metadata- og private værter afvises.
4. Brugernavn: kun til Dockers basic-auth; lad det stå tomt for npm og git, der kun bruger token.
5. Token/adgangskode: et token med kun læseadgang til det registry.

Tokenet gemmes krypteret (AES-256-GCM), bruges kun til dine egne Renovate-kørsler, returneres aldrig af API’et og vises, i modsætning til en Actions-secret, aldrig for dine CI-workflows. Renovate godkender sig over for det registry ved næste kørsel. Fjern et credential når som helst; opslag af dets pakker begynder så at fejle igen, indtil du tilføjer det igen.

Det er fremforges pendant til GitHubs registry-secrets til Dependabot.

Krydshenvisninger

• Renovates dokumentation (upstream), den fulde konfigurationsreference.
• Sikkerhed og forsyningskæde, hvordan Renovate passer ind i den bredere historie om forsyningskæden.
• Sikkerhedsrettelser, det andet spor: én pull request pr. sårbar pakke.
• Fejlfinding, når pull requests ikke åbnes, eller en kørsel fejler.
• Webhooks, Renovates pull requests udløser de samme pull_request-webhook-hændelser som enhver anden pull request.