Pakkecaches

fremforge kører ikke længere separate fælles caches for hostede runners. Cachen er din organisations egen afhængighedsproxy i samme EU-region som runner-VM’erne. Med runner pull-through slået til – standarden for alle organisationer, der ikke har gemt deres egne indstillinger for dependency proxyen – peges hvert job mod den, når det starter (se Hostede runnere):

Trafik	Peges mod din proxy af	Uden runner pull-through eller ved fallback
npm, pnpm (via jobbets npmrc)	registry-indstillingen for npm	`registry.npmjs.org`
pip og uv	`PIP_INDEX_URL`, `UV_DEFAULT_INDEX`	PyPI
Go, Maven, NuGet (hver især, når de står i `runner_pull_through_ecosystems`; alle som standard)	`GOPROXY`, et Maven-spejl af Central, en maskinglobal `NuGet.Config`	`proxy.golang.org`, Maven Central, nuget.org
Trivys sårbarhedsdatabase (når `trivy` står på listen)	`TRIVY_DB_REPOSITORY`, `TRIVY_JAVA_DB_REPOSITORY`	`ghcr.io/aquasecurity`
Container-images	jobbets Docker-daemon (se Container-images)	det registry, imaget nævner

Alle fallbacks går til det offentlige registry gennem fremforges udgående EU-proxy. Proxyen tjekkes ved starten af hvert job; kan den ikke nås, bruger jobbet de offentlige registre, og fallbacken logges.

Proxyen kører i samme OTC-region som runner-VM’erne (eu-de, Tyskland). Et miss hentes fra upstream gennem fremforges udgående trafik og caches til din organisations næste workflow.

Hvorfor det sker automatisk

En typisk installation af afhængigheder henter flere titals megabyte pakker ved hvert build. Uden cache krydser den trafik NAT-gatewayen og hentes fra det offentlige indeks hver gang. Med cache kommer varme pakker i stedet fra lager inden for regionen.

Du behøver ikke konfigurere noget: hvert værktøj respekterer automatisk sin indstilling. yarn og bun peges ikke mod proxyen; de installerer fra registry.npmjs.org gennem fremforges udgående proxy.

Tilsidesæt pr. workflow

For at tilsidesætte (f.eks. når du skal hente fra et privat registry) sætter du variablen i dit workflows env:

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

env: på step-niveau respekteres også. Din egen indstilling vinder altid over fremforges standard.

pnpm 11 læser ikke NPM_CONFIG_REGISTRY: sæt også PNPM_CONFIG_REGISTRY til samme URL, ellers bliver pnpm 11 ved med at installere fra registry.npmjs.org.

Container-images

Med runner pull-through slået til henter jobbets Docker-daemon container-images gennem din organisations dependency proxy, og de caches for din organisation: docker pull, docker run, en Dockerfiles FROM samt job- og services:-containerne. Image-navnene forbliver uændrede. Det dækker ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws og registry.access.redhat.com for alle organisationer. Kan proxyen ikke nås eller ikke levere en pull, hentes imaget direkte fra registryet. For images er proxyen en cache, ikke en gate. En docker buildx-builder med driveren docker-container henter direkte. Se Hostede runnere for detaljerne.

Images fra Docker Hub

Der er intet fælles Docker Hub-spejl, og DOCKER_MIRROR_URL sættes ikke længere. Docker Hub (docker.io) går ligesom registry.redhat.io og registry.connect.redhat.com kun gennem din proxy med din organisations egen legitimation. Uden den er en docker pull eller FROM af et Docker Hub-image i et workflow en anonym pull direkte fra Docker Hub, underlagt Docker Hubs rate limit for anonyme pulls.

Når en ejer har gemt din organisations Docker Hub-token i dependency proxyen, går Docker Hub-pulls i dine jobs gennem proxyen og caches, undtagen i jobs fra pull requests fra forks. Du kan også hente eksplicit gennem frem.sh/<org>/dependency-proxy/docker.io/. Se Hent Docker Hub-images gennem afhængighedsproxyen med dit eget Docker Hub-token.

`npm audit` og `pnpm audit` gennem dependency proxyen

npm audit og pnpm audit sender deres audit-forespørgsel til det registry, de installerer fra. Når det registry er din organisations dependency proxy (https://frem.sh/_app/proxy/<org>/npm/), som det er for jobs med runner pull-through slået til, besvarer proxyen selv forespørgslen i npm’s bulk-advisory-format ud fra fremforges eget advisory-indeks, bygget på data fra OSV. Forespørgslens body er din præcise liste over afhængigheder, og proxyen sender den ikke videre: den når aldrig registry.npmjs.org eller nogen anden tredjeparts advisory-tjeneste. Forespørgslen godkendes som alle andre proxy-forespørgsler, med et frem.sh-token, der kan læse pakker i organisationen.

Understøttede klienter: npm 7 og nyere samt pnpm 11 og nyere. Begge sender POST /-/npm/v1/security/advisories/bulk, det eneste audit-endpoint, proxyen betjener. Body kan være gzip-komprimeret, op til 4 MiB.
Ikke understøttet: npm 6 og pnpm 10 og ældre bruger de ældre audit-endpoints (/-/npm/v1/security/audits og /-/npm/v1/security/audits/quick), som proxyen besvarer med 404. Brug npm 7 eller nyere eller pnpm 11, eller giv pnpm --ignore-registry-errors.
pnpm 11 læser ikke NPM_CONFIG_REGISTRY. Den tager sit registry fra PNPM_CONFIG_REGISTRY, en .npmrc eller pnpm-workspace.yaml. Runner pull-through angiver proxyen i jobbets npmrc, som pnpm 11 læser. Peger du selv et job mod proxyen med NPM_CONFIG_REGISTRY, så sæt PNPM_CONFIG_REGISTRY til samme URL, ellers installerer pnpm 11 fra – og sender sin audit til – registry.npmjs.org.
Hvis advisory-indekset ikke kan læses, svarer proxyen 503 med Retry-After: 10 i stedet for en tom rapport, så et mislykket opslag får audit’en til at fejle i stedet for at se ud som “ingen sårbarheder”.
I rapporten peger advisory-URL’er på osv.dev, og hver titel slutter med OSV-id’et (f.eks. et GHSA-id). En kendt ondsindet version rapporteres som Malicious package (MAL-…). Det numeriske advisory-id, som npm viser, er afledt af OSV-id’et.

Hvad der IKKE caches

Private pakker. Proxyen henter npm, PyPI, Go, Maven, NuGet og de øvrige pakkeregistre anonymt, så den leverer kun offentlige pakker, og dit jobs egen Authorization-header sendes aldrig til upstream. Private ghcr.io- og quay.io-images samt Docker Hub og Red Hats registre bruger din organisations egen upstream-legitimation. Til et privat pakkeregistry tilsidesætter du den relevante variabel (NPM_CONFIG_REGISTRY, PIP_INDEX_URL, GOPROXY, …).
Dynamiske API-kald. API-kald i GitHub-stil (f.eks. npm view <package> mod api.npmjs.org) caches ikke; det gør kun registry-endpoints med pakkedata.
Kilde-repositorier. git clone-trafik til GitHub / GitLab / din egen forge caches ikke. Brug fremforges pakkeregister (https://frem.sh/api/packages/<org>/<type>/), når du selv styrer kilden.
Container-images fra andre registre. Images fra registre, som dependency proxyen ikke kender (gcr.io, et privat registry), hentes direkte. Docker Hub og Red Hats registre caches kun med din organisations egen legitimation; se Images fra Docker Hub. Konfigurér et privat registry direkte pr. workflow.

Forventet ydeevne

Kold cache (første pull af en ny pakkeversion): ca. 2-5 s langsommere end upstream; cachen henter fra upstream, gemmer i OBS og returnerer derefter. Samlet latenstid = upstream-pull + OBS-skrivning.
Varm cache (efterfølgende pulls af samme version): ca. 30-60 s hurtigere end upstream for en typisk npm ci-kørsel; cachen leverer fra OBS inden for regionen.
Cachens horisont: din opbevaringsindstilling, som standard 90 dage. En cachet fil, der ikke er hentet så længe, fjernes; pakkeversioner og base-images, som din organisation stadig bruger, beholdes. Se Retention.

Suverænitet

Dependency proxyen kører i fremforges eu-de-cluster, og dens lager er en OBS-bucket i eu-de. Det er fremforges egen software, bygget og udrullet som resten af platformen. Pulls fra upstream er anonyme, medmindre din organisation har gemt sin egen legitimation til den pågældende upstream (for eksempel Docker Hub); se Upstream credentials.

Hvad upstream-registrene modtager, er beskrevet under Hvad upstream ser. Hver pull registreres i din organisations adgangslog for registret (for cache-hits fra CI i Hentede pakkeversioner). Databehandleraftalen (DPA) dækker begge: adgangsloggen i bilag A.6 og upstream-registrene, som vælges efter din instruks og ikke er underdatabehandlere, i bilag B §B.9.

Status og hændelseshåndtering

Dependency proxyen overvåges. Hvert job tjekker den, når det starter: kan den ikke nås, installerer og henter det pågældende job i stedet fra de offentlige registre gennem fremforges udgående trafik, og fallbacken logges. Forventet konsekvens: ca. 30-60 s ekstra pr. ikke-cachet pull. En proxy, der fejler midt i et job, rutes der ikke uden om: npm og pnpm prøver igen, og en travl proxy svarer 503 med Retry-After (se Errors).

Relateret

Runner-image: hvad der er bagt ind i det hostede runner-image (kaniko, buildkit, sprog-toolchains)
Secrets: sådan injicerer du legitimation til private registre pr. workflow
Udgående trafik, tilladte destinationer og den udgående proxys adfærd er beskrevet under CI-runners