Pakkebuffere

fremforge kjører ikke lenger egne delte buffere for hostede runnere. Bufferen er organisasjonens egen avhengighetsproxy, i samme EU-region som runner-VM-ene. Med runner pull-through slått på – standard for alle organisasjoner som ikke har lagret egne innstillinger for avhengighetsproxyen – blir hver jobb pekt mot den når den starter (se Hosted runners):

All reservetrafikk går til det offentlige registeret gjennom fremforges utgående proxy i EU. Proxyen sjekkes ved starten av hver jobb; kan den ikke nås, bruker jobben de offentlige registrene, og reserveløsningen logges.

Proxyen kjører i samme OTC-region som runner-VM-ene (eu-de, Tyskland). Det som mangler i bufferen, hentes fra upstream gjennom fremforges utgående trafikk og bufres til organisasjonens neste workflow.

Hvorfor dette skjer automatisk

En typisk installasjon av avhengigheter henter titalls megabyte med pakker i hvert bygg. Uten buffer krysser den trafikken NAT-gatewayen og hentes fra den offentlige indeksen hver gang. Med buffer kommer varme pakker i stedet fra lagring i samme region.

Du trenger ikke konfigurere noe: hvert verktøy følger innstillingen sin automatisk. yarn og bun pekes ikke mot proxyen; de installerer fra registry.npmjs.org gjennom fremforges utgående proxy.

Overstyr per workflow

For å overstyre (f.eks. når du må hente fra et privat register) setter du variabelen i workflowens env:

jobs:
  build:
    runs-on: fremforge
    env:
      NPM_CONFIG_REGISTRY: https://npm.your-company.example/
    steps:
      - run: npm ci

env: på stegnivå respekteres også. Kundens innstilling vinner alltid over fremforges standard.

pnpm 11 leser ikke NPM_CONFIG_REGISTRY: sett også PNPM_CONFIG_REGISTRY til samme URL, ellers fortsetter pnpm 11 å installere fra registry.npmjs.org.

Containerimager

Med runner pull-through slått på puller jobbens Docker-daemon containerimager gjennom organisasjonens avhengighetsproxy, og de bufres for organisasjonen din: docker pull, docker run, FROM i en Dockerfile, og jobb- og services:-containerne. Imagenavnene forblir som de er. Dette dekker ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws og registry.access.redhat.com for alle organisasjoner. Hvis proxyen ikke kan nås, eller ikke kan levere en pull, hentes imaget direkte fra registeret. For imager er proxyen en buffer, ikke en sperre. En docker buildx-builder med driveren docker-container puller direkte. Se Hosted runners for detaljene.

Docker Hub-imager

Det finnes ikke noe delt Docker Hub-speil, og DOCKER_MIRROR_URL settes ikke lenger. Docker Hub (docker.io) går, i likhet med registry.redhat.io og registry.connect.redhat.com, gjennom proxyen bare med organisasjonens egen legitimasjon. Uten den er en docker pull eller FROM av et Docker Hub-image i en workflow en anonym pull rett fra Docker Hub, underlagt Docker Hubs hastighetsgrense for anonyme pulls.

Når en eier har lagret organisasjonens Docker Hub-token i avhengighetsproxyen, går Docker Hub-pulls i jobbene dine gjennom proxyen og bufres, unntatt i jobber fra pull requests fra forks. Du kan også pulle eksplisitt gjennom frem.sh/<org>/dependency-proxy/docker.io/. Se Pull Docker Hub-imager gjennom avhengighetsproxyen med ditt eget Docker Hub-token.

npm audit og pnpm audit gjennom avhengighetsproxyen

npm audit og pnpm audit sender audit-forespørselen sin til registeret de installerer fra. Når det registeret er organisasjonens avhengighetsproxy (https://frem.sh/_app/proxy/<org>/npm/), slik det er for jobber med runner pull-through slått på, svarer proxyen selv på forespørselen, i npms format for samlede sårbarhetsvarsler, fra fremforges egen varselindeks bygget på data fra OSV. Forespørselens body er den nøyaktige listen over avhengighetene dine, og proxyen videresender den ikke: den når aldri registry.npmjs.org eller noen annen tredjepartstjeneste for sårbarhetsvarsler. Forespørselen autentiseres som alle andre proxyforespørsler, med et frem.sh-token som kan lese pakker i organisasjonen.

• Støttede klienter: npm 7 og nyere, og pnpm 11 og nyere. Begge sender POST /-/npm/v1/security/advisories/bulk, det ene audit-endepunktet proxyen betjener. Bodyen kan være gzippet, opptil 4 MiB.
• Ikke støttet: npm 6 og pnpm 10 og eldre bruker de eldre audit-endepunktene (/-/npm/v1/security/audits og /-/npm/v1/security/audits/quick), som proxyen svarer 404 på. Bruk npm 7 eller nyere eller pnpm 11, eller send --ignore-registry-errors til pnpm.
• pnpm 11 leser ikke NPM_CONFIG_REGISTRY. Den henter registeret sitt fra PNPM_CONFIG_REGISTRY, en .npmrc eller pnpm-workspace.yaml. Runner pull-through oppgir proxyen i jobbens npmrc, som pnpm 11 leser. Peker du selv en jobb mot proxyen med NPM_CONFIG_REGISTRY, setter du PNPM_CONFIG_REGISTRY til samme URL, ellers installerer pnpm 11 fra, og sender audit-forespørselen til, registry.npmjs.org.
• Hvis varselindeksen ikke kan leses, svarer proxyen 503 med Retry-After: 10 i stedet for en tom rapport, slik at et mislykket oppslag får audit-kjøringen til å feile i stedet for å se ut som «ingen sårbarheter».
• I rapporten peker URL-ene til varslene mot osv.dev, og hver tittel slutter med OSV-ID-en (for eksempel en GHSA-ID). En kjent ondsinnet versjon rapporteres som Malicious package (MAL-…). Den numeriske varsel-id-en som npm viser, er avledet fra OSV-ID-en.

Hva som IKKE bufres

• Private pakker. Proxyen henter npm, PyPI, Go, Maven, NuGet og de andre pakkeregistrene anonymt, så den leverer bare offentlige pakker, og jobbens egen Authorization-header sendes aldri videre til upstream. Private ghcr.io- og quay.io-imager, og Docker Hub og Red Hat-registrene, bruker organisasjonens egen upstream-legitimasjon. For et privat pakkeregister overstyrer du den aktuelle variabelen (NPM_CONFIG_REGISTRY, PIP_INDEX_URL, GOPROXY, …).
• Dynamiske API-kall. API-kall i GitHub-stil (f.eks. npm view <package> mot api.npmjs.org) bufres ikke, bare registerendepunktene for pakkedata.
• Kilderepositoryer. git clone-trafikk til GitHub / GitLab / din egen forge bufres ikke. Bruk fremforges pakkeregister (https://frem.sh/api/packages/<org>/<type>/) når du kontrollerer kilden.
• Containerimager fra andre registre. Imager fra registre avhengighetsproxyen ikke kjenner (gcr.io, et privat register), pulles direkte. Docker Hub og Red Hat-registrene bufres bare med organisasjonens egen legitimasjon; se Docker Hub-imager. Sett opp et privat register direkte per workflow.

Forventet ytelse

• Kald buffer (første pull av en ny pakkeversjon): ~2–5 s tregere enn upstream, bufferen henter fra upstream, lagrer i OBS og returnerer deretter. Netto ventetid = pull fra upstream + skriving til OBS.
• Varm buffer (senere pulls av samme versjon): ~30–60 s raskere enn upstream for en typisk npm ci-kjøring, bufferen leverer fra OBS i samme region.
• Bufferhorisont: oppbevaringsinnstillingen din, 90 dager som standard. En bufret fil som ikke er pullet på så lenge, fjernes; pakkeversjoner og base-imager som organisasjonen fortsatt bruker, beholdes. Se Retention.

Suverenitet

Avhengighetsproxyen kjører i fremforges eu-de-klynge, og lageret er en OBS-bøtte i eu-de. Det er fremforges egen programvare, bygget og rullet ut som resten av plattformen. Pulls fra upstream er anonyme med mindre organisasjonen har lagret egen legitimasjon for den upstreamen (for eksempel Docker Hub); se Upstream credentials.

Hva upstream-registrene mottar, er beskrevet under What the upstream sees. Hver pull registreres i organisasjonens tilgangslogg for registeret (for treff i CI-bufferen: pull census). Databehandleravtalen dekker begge deler: tilgangsloggen i vedlegg A.6, og upstream-registrene, som velges etter din instruks og ikke er underdatabehandlere, i vedlegg B §B.9.

Status og hendelseshåndtering

Avhengighetsproxyen overvåkes. Hver jobb sjekker den når den starter: kan den ikke nås, installerer og puller den jobben i stedet fra de offentlige registrene gjennom fremforges utgående trafikk, og reserveløsningen logges. Forventet konsekvens: ~30–60 s ekstra per pull som ikke er bufret. En proxy som feiler midt i en jobb, rutes det ikke rundt: npm og pnpm prøver på nytt, og en travel proxy svarer 503 med Retry-After (se Errors).

Relatert

• Runner-image: hva som er bakt inn i det hostede runner-imaget (kaniko, buildkit, språkverktøykjeder)
• Secrets: hvordan du legger inn legitimasjon for private registre per workflow
• Utgående trafikk, tillatte mål og oppførselen til den utgående proxyen er beskrevet under CI-runnere