Versjonsoppdateringer

Versjonsoppdateringer er sporet med hostet Renovate i Avhengighetsoppdateringer. Slå det på for en organisasjon, så åpner fremforge grupperte pull requests som er lette å gå gjennom, etter tidsplanen i renovate.json: npm, gomod, Terraform-providere, base-imager i Dockerfile, Helm-charts og enhver egendefinert regex-pin. Repositoryene i hver påmeldte organisasjon kjøres hver natt; se Kadens.

Sårbare avhengigheter som skanningene dine finner, er det andre sporets jobb: Sikkerhetsrettelser åpner én pull request per sårbar pakke. Inntil sporet Sikkerhetsrettelser tar over for organisasjonen din, åpner hostet Renovate også sine egne pull requests for sikkerhet for OSV-sårbarhetsvarsler, som beskrevet nedenfor.

Inkludert i planen til 30 € per bruker. Ikke noe tilleggsnivå, ingen action-minutter hos tredjeparter og ikke selskapet GitHub i dataflyten.

Hva du får

• Automatiske pull requests for utdaterte avhengigheter, fornuftig gruppert: én pull request per sett med beslektede pakker i stedet for dusinvis av enlinjes oppgraderinger.
• Pull requests utløst av sårbarheter for publiserte sårbarhetsvarsler (OSV). De åpnes av neste kjøring i stedet for å vente på tidsplanen din, og holdes ikke tilbake av ventetiden for utgivelsesalder som er beskrevet under Plattformpolicy (for npm, se det ene unntaket der). Når sporet Sikkerhetsrettelser tar over for en organisasjon, slås disse av der, så en rettelse foreslås bare én gang.
• Et Dependency Dashboard-issue fra Renovate i hvert repository, så du ser status med ett blikk.
• Hele konfigurasjonsskjemaet til Renovate: alle alternativer på docs.renovatebot.com virker uendret på fremforge. Reglene dine legges oppå plattformpolicyen.
• En botbruker per organisasjon, <org>-fremforge-bot-deps, avgrenset til bare din organisasjon; tokenet krysser aldri grensen mellom organisasjoner. Sikkerhetsrettelser bruker den samme boten.
• EU-suverent: kjører på T Cloud Public CCE, uten SaaS fra tredjeparter i dataflyten.

Slå på

1. Åpne Sikkerhet › Utbedre › Avhengighetsoppdateringer (eller Bygg og utrulling › Avhengighetsoppdateringer) og gå til Versjonsoppdateringer.
2. Slå på hostet Renovate.
3. fremforge klargjør en botbruker for organisasjonen, <org>-fremforge-bot-deps, og gir den skrivetilgang til organisasjonens repositoryer.
4. Repositoryene plukkes opp av neste nattlige kjøring, eller med en gang med Kjør nå; deretter følger pull requestene tidsplanen i renovate.json.

Når du slår det på, får organisasjonen også standardinnstillingene for Sikkerhetsrettelser: pull requests med rettelser ved klikk, som venter på gjennomgang.

Botbrukeren styres av fremforge. Du trenger ikke opprette den, rotere legitimasjonen dens eller bekymre deg for tapte passord. Tokenet styres av plattformen og roteres automatisk.

Slå av

1. Sikkerhet › Utbedre › Avhengighetsoppdateringer → Versjonsoppdateringer → slå av hostet Renovate.
2. fremforge tilbakekaller botens token umiddelbart og fjerner boten fra organisasjonen, med mindre Sikkerhetsrettelser står i en automatisk modus: da blir boten værende, bare for sikkerhetsrettelser.
3. Pull requests som Renovate allerede har åpnet, forblir åpne. Merge eller lukk dem som enhver annen pull request.
4. Organisasjonens renovate.json blir liggende i repositoryene dine; fremforge rører den ikke.

Slår du det på igjen, klargjøres en ny bot. Det forrige botbrukernavnet settes på gravsteinslisten (gjenbrukes ikke), så revisjonshistorikken forblir ren.

Plattformpolicy

Hver kjøring starter fra fremforges policy, og renovate.json legges oppå den.

• Kadens. Repositoryene i hver påmeldte organisasjon settes i kø for en kjøring hver natt (fra 02:30 UTC); et repository som har kjørt de siste 4 timene, hoppes over. En schedule i renovate.json begrenser fortsatt når vanlige pull requests åpnes. Sikkerhetsoppdateringer (sårbarhetsvarsler) ignorerer den tidsplanen og ventetiden for utgivelsesalder, og åpnes av neste kjøring etter at sårbarhetsvarselet er publisert. Kjør nå starter en kjøring utenom syklusen.
• Ventetid for utgivelsesalder. En vanlig oppdatering foreslås først når den nye versjonen er like gammel som organisasjonens utgivelsesalder (3 dager med mindre en eier har endret den), så en ondsinnet eller ødelagt utgivelse som trekkes tilbake i løpet av noen dager, aldri når deg. Registre som ikke publiserer en utgivelsesdato, får ingen ventetid. Sikkerhetsoppdateringer hopper over ventetiden, med ett unntak for npm: en rettet versjon som er yngre enn utgivelsesalderen, tilbys bare når npms data om sårbarhetsvarsler oppgir at den retter versjonen du har. En rettelse som disse dataene ikke oppgir, venter som en vanlig oppdatering.
• Ventetiden gjelder også låsefilen din. Renovate foreslår en versjon, og pakkebehandleren din løser deretter opp låsefilen, inkludert eventuelle nye transitive avhengigheter. For npm, pnpm og Yarn 1 går den oppløsningen gjennom fremforges visning av npm-registeret etter utgivelsesalder, så en utvidet versjonsrange kan ikke låse en versjon som er yngre enn 3 dager. Visningen holder 3 dager for alle organisasjoner; med en lengre utgivelsesalder holder sjekken nedenfor pull requesten tilbake til låsefilen er gammel nok. Din egen .npmrc brukes fortsatt etter den, så dine private scopes og en eventuell egen registry=-linje går foran. Yarn 2+ leser .yarnrc.yml i stedet og dekkes ikke av visningen; sjekken nedenfor holder likevel de pull requestene tilbake.
• Sjekken fremforge/release-age. Hver pull request får denne sjekken, og den er en påkrevd sjekk i branchbeskyttelsen. På en pull request med avhengighetsoppdateringer står den som ventende med teksten «Waiting until …» til hver versjon som låsefilen løser opp til, er like gammel som utgivelsesalderen din. Deretter blir den grønn av seg selv i løpet av minutter, uten en ny push, og auto-merge venter på den. En versjon som et gjennomgått sårbarhetsvarsel (uansett alvorlighetsgrad) på basebranchen din navngir som sin rettelse, venter i stedet 24 timer, og det samme gjør en ny avhengighet som bare den rettelsen har tatt med fra de samme utgiverne (sporet for sikkerhetsrettelser). En rettelse for en kjent utnyttet sårbarhet holdes ikke tilbake. På en pull request som en person har åpnet, rapporteres ferske versjoner, men de holder ikke pull requesten tilbake. Settes skanneren til off for en organisasjon eller et repository, fjernes sjekken fra branchbeskyttelsen innen en time.
• Auto-merge. Oppdateringer av typen patch, pin og digest auto-merges som standard når CI er grønn. Minor-oppdateringer auto-merges hvis du slår det på i policyinnstillingene. Major-oppdateringer venter alltid på godkjenningen din i Dependency Dashboard.
• Pakker med stort skadeomfang. Omtrent 30 pakker for autentisering, kryptografi, databaser, ORM og sky-KMS (for eksempel jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) auto-merger aldri en vanlig oppdatering; pull requesten venter på gjennomgang. OpenID-biblioteker kan auto-merge en patch, men aldri en minor eller major.
• Sikkerhetsoppdateringer. Om hostet Renovates egne pull requests for sikkerhet auto-merges når CI er grønn, styres av innstillingen Når rettelser merges under Sikkerhetsrettelser: Merge når sjekkene går gjennom eller Vent på gjennomgang (standard). Organisasjoner som hadde den tidligere auto-merge for Security updates slått på, noe som var standard for alle påmeldte organisasjoner, ble flyttet til Merge når sjekkene går gjennom, så ingenting endret seg for dem. Med den auto-merges en pull request for sikkerhet for alle pakker, også dem med stort skadeomfang: det er nettopp de bibliotekene du helst vil ha rettet raskt. Se Merging.
• Merge-vindu. En organisasjonsadministrator kan begrense når pull requests fra Renovate klargjøres for merge, som hele UTC-timer på valgte ukedager (merge_window i PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). Utenfor vinduet klargjøres ingen pull request fra Renovate, og klargjøringer som boten har gjort, avbrytes når vinduet lukkes; en klargjøring som en person har gjort, blir latt være. Et repository med et åpent issue med etiketten release-freeze klargjøres aldri.
• Rettelser for kjent utnyttede sårbarheter. En sikkerhetsoppdatering for en CVE som utnyttes i praksis (oppført i ENISAs EU Vulnerability Database eller CISAs katalog Known Exploited Vulnerabilities, sjekket daglig), åpnes før alle andre oppdateringer i kjøringen, holdes ikke tilbake av grensene for pull requests, og får etiketten known-exploited (når repositoryet ditt har den etiketten) og en merknad i beskrivelsen av pull requesten. Den klargjøres også utenfor merge-vinduet, så den merges så snart sjekkene er bestått. Bare vinduet hoppes over: en pull request klargjøres utenfor det bare hvis den ville blitt klargjort innenfor det, og utgivelsesfrysen, en person som avbryter auto-merge, og de påkrevde sjekkene dine gjelder fortsatt.
• Reglene dine vinner. Reglene i renovate.json brukes etter denne policyen, så en automerge: true-regel der overstyrer den, også gjennomgangskravet for pakker med stort skadeomfang. Legger du til en slik regel, bør du utelate de pakkene fra den (se eksemplet nedenfor).

Innstillinger

En eier setter policyen for sporet på siden, eller med PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (scope dependency-updates:write). Alle felt er valgfrie; et felt som utelates, beholder verdien sin, og et ukjent felt avvises med unknown-field.

GET på den samme stien returnerer de samme feltene, med den samme snake_case-skrivemåten. security_automerge er ikke et felt her: om pull requests for sikkerhet merger seg selv, er innstillingen merge under Sikkerhetsrettelser, og sender du security_automerge til denne stien, avvises det med en melding som sier nettopp det.

Konfigurasjon

Konfigurasjon per repository skjer via renovate.json i roten av repositoryet. Uten den bruker Renovate fornuftige standardverdier, noe som som regel holder den første måneden mens du ser hva slags pull requests som kommer inn.

Et minimalt utgangspunkt:

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

En mer meningsbærende konfigurasjon som grupperer OpenTelemetry-pakker, auto-merger oppgraderinger av patch og låsefil, og krever menneskelig gjennomgang av major-oppgraderinger:

{
  "$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-regelen i dette eksemplet brukes etter plattformpolicyen, så den ville også auto-merge pakkene for autentisering, kryptografi og databaser som fremforge ellers holder tilbake for gjennomgang. For å beholde dem manuelle utelater du dem fra regelen, for eksempel "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

Den fullstendige referansen for Renovate-konfigurasjon finner du på docs.renovatebot.com/configuration-options/.

Hva som oppgraderes

Renovate oppdager de fleste økosystemer automatisk uten konfigurasjon. Automatisk oppdagede økosystemer på fremforge:

• npm / pnpm / yarn: package.json + vedlikehold av låsefil
• Go-moduler: go.mod
• OpenTofu / Terraform: providerversjoner i versions.tf
• Dockerfile: FROM-linjer, med mulighet for å pinne digest
• Helm: chart-versjoner i values.yaml og Chart.yaml
• Egendefinerte regex-pins: for enhver versjonsstreng i enhver fil (fint for å pinne binærfiler som installeres av skallskript)
• Python: pyproject.toml, requirements*.txt, Pipfile og Poetry. Hash-pinnede requirements kompilert med uv pip compile eller pip-compile låses på nytt som en helhet; se Kompilerte Python-requirements.

Den fullstendige økosystemmatrisen finner du på docs.renovatebot.com/modules/manager/.

Kompilerte Python-requirements

En requirements*.txt som er skrevet av uv pip compile eller pip-compile, pinner hver pakke, ofte med --hash-linjer. Noen oppgraderinger krever også at en annen pin flytter seg. For eksempel pinner pydantic pydantic-core til én eksakt versjon. Når hodet i låsen navngir kommandoen som skrev den, kjører hostet Renovate den kommandoen på nytt med --upgrade-package, så pull requesten med oppdateringen inneholder hele den nylåste filen: den oppgraderte pakken, hver pin den flytter, og hashene deres. Uten den nye låsingen endrer pull requesten én linje, og pip install --require-hashes avviser den.

Hostet Renovate gjør dette for enhver requirements*.txt med en kompileringskommando i hodet, i alle organisasjoner. Du trenger ikke konfigurere noe, så lenge hodet følger Renovates regler:

• Bruk lange alternativnavn, og knytt hver verdi til med =, for eksempel --output-file=requirements.txt, --python-version=3.11, --extra=dev og --group=dev. uv skriver kommandoen inn i hodet nøyaktig slik du skrev den. Renovate avviser -o requirements.txt og --python-version 3.11, og lar da den låsen være.
• Navngi kildefilen, for eksempel uv pip compile pyproject.toml .... Et hode uten kildefil (for eksempel uv pip compile --group render ...) låses ikke på nytt.
• Gi hver direkte avhengighet en versjonsbegrensning. En avhengighet som er skrevet helt uten versjon ("httpx"), låses ikke på nytt; oppgraderingen endrer bare dens egen linje. Et gulv som "httpx>=0.28" er nok.

Et hode som 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 låser på nytt, så sett den til den eldste Python-versjonen du støtter. Den nylåste filen er den samme filen som din egen kompilering ville produsert, og den registrerer ingen indeks-URL.

Den nye låsingen løses opp mot offentlige PyPI, den samme indeksen som Renovate bruker for å finne den nye versjonen, med mindre hodet eller pyproject.toml navngir en annen indeks. En håndskrevet requirements.txt uten kompileringshode oppdateres én linje om gangen, som før.

Kjøringer utenom syklusen

Trenger du en Renovate-kjøring før neste planlagte syklus (for eksempel fordi du nettopp har publisert en ny renovate.json og vil se hva den gir)?

1. Sikkerhet › Utbedre › Avhengighetsoppdateringer → Kjør nå.
2. Begrenset til én kjøring utenom syklusen per time per organisasjon.
3. Resultatene vises under Aktivitet i løpet av noen minutter.

Pull requests utløst av sårbarheter går allerede automatisk utenom syklusen. Du trenger ikke klikke Kjør nå når en ny CVE dukker opp; Renovates egen planlegger for sårbarheter tar seg av det.

Tilpasning av kadens

Renovates felt schedule godtar cron-lignende uttrykk. Noen vanlige mønstre:

• ["before 4am on the first day of the month"]: én gang i måneden. (fremforges standard er ingen tidsplan: en kjøring hver natt, og pull requests kan åpnes ved enhver kjøring.)
• ["before 4am every weekday"]: daglig på hverdager.
• ["after 9pm and before 5am"]: bare utenfor arbeidstid.
• []: aldri; stol bare på kjøringer utløst av sårbarheter.

Feltet vulnerabilityAlerts.schedule overstyrer for pull requests for sikkerhet:

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

Kostnad

Inkludert i planen til 30 € per bruker. Ingen måling, ingen pris per pull request og ingen egen linje for runner-minutter.

Til sammenligning: GitHubs Dependabot er gratis, men Dependabot Updates som kjører på Actions, bruker Actions-minuttene dine. fremforges hostede Renovate kjører på CCE-infrastruktur som fremforge styrer (atskilt fra runner-poolen for CI-en din, så den bruker aldri runner-minutter). Det er den praktiske forskjellen.

Hvorfor Renovate og ikke Dependabot

Renovate er OSS-verktøyet vi kjører mot våre egne repositoryer, med samme konfigurasjon, samme kadens og samme form på pull requestene, og som vi valgte å tilby som den hostede funksjonen for avhengighetsoppdateringer. Renovate har hatt innebygd støtte for Forgejo siden v37; konfigurasjonsskjemaet er bredere enn Dependabots, og det støtter egendefinerte regex-pins, noe Dependabot ikke gjør. De fleste team som bruker begge, foretrekker Renovate.

Du kan også hoste Renovate selv mot dine egne fremforge-repositoryer uten å melde deg på den hostede versjonen. Legg inn en renovate.json og kjør Renovate selv i CI. Den hostede versjonen er bekvemmelighetslaget; OSS-konfigurasjonen for Renovate som du skriver, er den samme uansett.

Private registre

Legg til en lesetilgang under Sikkerhet › Utbedre › Avhengighetsoppdateringer → Versjonsoppdateringer → Private registre:

1. Label: et navn til eget bruk (for eksempel «GitHub Packages»).
2. Type: npm, docker eller git (en privat Git-vert for oppslag av moduler og tagger, for eksempel en privat kilde for Terraform-moduler).
3. Vert / register-URL: registerverten (for eksempel npm.pkg.github.com) eller et https://-URL-prefiks. Loopback-, metadata- og private adresseområder avvises.
4. Brukernavn: bare for basic-auth i Docker; la feltet stå tomt for npm og git med bare token.
5. Token / passord: et token med bare lesetilgang for det registeret.

Tokenet lagres kryptert (AES-256-GCM), brukes bare til dine egne Renovate-kjøringer, returneres aldri av API-et og eksponeres, i motsetning til en Actions-secret, aldri for CI-workflowene dine. Renovate autentiserer seg mot registeret ved neste kjøring. Du kan fjerne en tilgang når som helst; oppslag av pakkene dens begynner da å feile igjen til du legger den til på nytt.

Dette er fremforges motstykke til GitHubs registersecrets for Dependabot.

Se også

• Renovate-dokumentasjonen (upstream), full konfigurasjonsreferanse.
• Sikkerhet og forsyningskjede, hvordan Renovate passer inn i det større bildet av forsyningskjeden.
• Sikkerhetsrettelser, det andre sporet: én pull request per sårbar pakke.
• Feilsøking, når pull requests ikke åpnes eller en kjøring feiler.
• Webhooks, Renovates pull requests utløser de samme pull_request-webhookhendelsene som enhver annen pull request.