Paketcacher

fremforge driver inte längre separata delade cacher för hostade runners. Cachen är din organisations egen beroendeproxy, i samma EU-region som runnerns VM:ar. Med runner pull-through påslaget, vilket är standard för alla organisationer som inte har sparat egna inställningar för beroendeproxyn, pekas varje jobb mot den när det startar (se Hosted runners):

Varje reservväg går till det publika registret via fremforges utgående proxy i EU. Proxyn kontrolleras i början av varje jobb; om den inte går att nå använder jobbet de publika registren och reservvägen loggas.

Proxyn körs i samma OTC-region som runnerns VM:ar (eu-de, Tyskland). Det som saknas i cachen hämtas från upstream via fremforges utgående trafik och cachas till organisationens nästa arbetsflöde.

Varför det sker automatiskt

En typisk installation av beroenden hämtar tiotals megabyte paket vid varje bygge. Utan cache passerar den trafiken NAT-gatewayen och hämtas från det publika indexet varje gång. Med cache kommer redan cachade paket i stället från lagring inom regionen.

Du behöver inte konfigurera något: varje verktyg följer sin inställning automatiskt. yarn och bun pekas inte mot proxyn; de installerar från registry.npmjs.org via fremforges utgående proxy.

Åsidosätt per arbetsflöde

För att åsidosätta (t.ex. när du behöver hämta från ett privat register) sätter du variabeln i arbetsflödets env:

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

env: på stegnivå respekteras också. Kundens inställning vinner alltid över fremforges standard.

pnpm 11 läser inte NPM_CONFIG_REGISTRY: sätt även PNPM_CONFIG_REGISTRY till samma URL, annars fortsätter pnpm 11 att installera från registry.npmjs.org.

Container-images

Med runner pull-through påslaget hämtar jobbets Docker-daemon container-images via din organisations beroendeproxy, och de cachas för din organisation: docker pull, docker run, en Dockerfiles FROM samt jobbets och services:-containrarna. Imagenamnen förblir oförändrade. Det omfattar ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws och registry.access.redhat.com för alla organisationer. Om proxyn inte går att nå, eller inte kan leverera en pull, hämtas imagen direkt från registret. För images är proxyn en cache, inte en spärr. En docker buildx-builder med drivrutinen docker-container hämtar direkt. Se Hosted runners för detaljerna.

Images från Docker Hub

Det finns ingen delad spegel av Docker Hub, och DOCKER_MIRROR_URL sätts inte längre. Docker Hub (docker.io) går, liksom registry.redhat.io och registry.connect.redhat.com, via din proxy bara med organisationens egna inloggningsuppgifter. Utan sådana är en docker pull eller FROM av en Docker Hub-image i ett arbetsflöde en anonym hämtning direkt från Docker Hub, som omfattas av Docker Hubs hastighetsbegränsning för anonyma hämtningar.

När en ägare har lagrat organisationens Docker Hub-token i beroendeproxyn går hämtningar från Docker Hub i dina jobb via proxyn och cachas, utom i jobb från pull requests från forkar. Du kan också hämta uttryckligen via frem.sh/<org>/dependency-proxy/docker.io/. Se Hämta Docker Hub-images via beroendeproxyn med din egen Docker Hub-token.

npm audit och pnpm audit via beroendeproxyn

npm audit och pnpm audit skickar sin granskningsförfrågan till registret de installerar från. När det registret är din organisations beroendeproxy (https://frem.sh/_app/proxy/<org>/npm/), vilket det är för jobb med runner pull-through påslaget, besvarar proxyn själv förfrågan, i npm:s format för bulk-advisories, från fremforges eget advisory-index byggt på data från OSV. Förfrågans kropp är din exakta beroendelista, och proxyn vidarebefordrar den inte: den når aldrig registry.npmjs.org eller någon annan tredjepartstjänst för advisories. Förfrågan autentiseras som alla andra proxyförfrågningar, med en frem.sh-token som kan läsa paket i organisationen.

• Klienter som stöds: npm 7 och senare samt pnpm 11 och senare. Båda skickar POST /-/npm/v1/security/advisories/bulk, den enda granskningsendpoint som proxyn tillhandahåller. Kroppen får vara gzip-komprimerad, upp till 4 MiB.
• Stöds inte: npm 6 och pnpm 10 och tidigare använder de äldre granskningsendpointarna (/-/npm/v1/security/audits och /-/npm/v1/security/audits/quick), som proxyn besvarar med 404. Använd npm 7 eller senare eller pnpm 11, eller skicka --ignore-registry-errors till pnpm.
• pnpm 11 läser inte NPM_CONFIG_REGISTRY. Det hämtar sitt register från PNPM_CONFIG_REGISTRY, en .npmrc eller pnpm-workspace.yaml. Runner pull-through anger proxyn i jobbets npmrc, som pnpm 11 läser. Om du själv pekar ett jobb mot proxyn med NPM_CONFIG_REGISTRY, sätt PNPM_CONFIG_REGISTRY till samma URL, annars installerar pnpm 11 från, och skickar sin granskning till, registry.npmjs.org.
• Om advisory-indexet inte går att läsa svarar proxyn 503 med Retry-After: 10 i stället för en tom rapport, så att en misslyckad uppslagning får granskningen att misslyckas i stället för att se ut som ”inga sårbarheter”.
• I rapporten pekar advisory-URL:erna till osv.dev, och varje titel slutar med OSV-id:t (till exempel ett GHSA-id). En känd skadlig version rapporteras som Malicious package (MAL-…). Det numeriska advisory-id som npm visar härleds från OSV-id:t.

Vad som INTE cachas

• Privata paket. Proxyn hämtar från npm, PyPI, Go, Maven, NuGet och de andra paketregistren anonymt, så den levererar bara publika paket, och jobbets egen Authorization-header skickas aldrig till upstream. Privata images från ghcr.io och quay.io, samt Docker Hub och Red Hats register, använder organisationens egna inloggningsuppgifter för upstream. För ett privat paketregister åsidosätter du den relevanta variabeln (NPM_CONFIG_REGISTRY, PIP_INDEX_URL, GOPROXY, …).
• Dynamiska API-anrop. API-anrop i GitHub-stil (t.ex. npm view <package> mot api.npmjs.org) cachas inte, bara registrens endpoints för paketdata.
• Källkodsrepon. Trafik från git clone mot GitHub / GitLab / din egen forge cachas inte. Använd fremforges paketregister (https://frem.sh/api/packages/<org>/<type>/) när du själv styr över källan.
• Container-images från andra register. Images från register som beroendeproxyn inte känner till (gcr.io, ett privat register) hämtas direkt. Docker Hub och Red Hats register cachas bara med organisationens egna inloggningsuppgifter; se Images från Docker Hub. Konfigurera ett privat register direkt per arbetsflöde.

Förväntad prestanda

• Kall cache (första hämtningen av en ny paketversion): ~2–5 s långsammare än upstream: cachen hämtar från upstream, sparar i OBS och svarar sedan. Nettolatens = hämtning från upstream + skrivning till OBS.
• Varm cache (senare hämtningar av samma version): ~30–60 s snabbare än upstream för en typisk körning av npm ci, eftersom cachen levererar från OBS inom regionen.
• Cachens horisont: din inställning för lagringstid, 90 dagar som standard. En cachad fil som inte har hämtats på så lång tid tas bort; paketversioner och basimages som organisationen fortfarande använder behålls. Se Lagringstid.

Suveränitet

Beroendeproxyn körs i fremforges kluster i eu-de, och dess lagring är en OBS-bucket i eu-de. Den är fremforges egen programvara, byggd och driftsatt som resten av plattformen. Hämtningar från upstream är anonyma om inte organisationen har lagrat egna inloggningsuppgifter för just den upstreamen (till exempel Docker Hub); se Inloggningsuppgifter för upstream.

Vad upstream-registren får ta del av beskrivs under Vad upstream ser. Varje hämtning registreras i organisationens åtkomstlogg för registret (för cacheträffar från CI, pull-censusen). Personuppgiftsbiträdesavtalet (DPA) täcker båda: åtkomstloggen i bilaga A.6, och upstream-registren, som väljs på din instruktion och inte är underbiträden, i bilaga B §B.9.

Status och incidenthantering

Beroendeproxyn övervakas. Varje jobb kontrollerar den när det startar: om den inte går att nå installerar och hämtar jobbet i stället från de publika registren via fremforges utgående trafik, och reservvägen loggas. Förväntad påverkan: ~30–60 s extra per hämtning som inte är cachad. En proxy som slutar fungera mitt i ett jobb kringgås inte: npm och pnpm gör omförsök, och en överbelastad proxy svarar 503 med Retry-After (se Fel).

Relaterat

• Runner-image: vad som är inbyggt i den hostade runner-imagen (kaniko, buildkit, språkverktyg)
• Secrets: hur du injicerar inloggningsuppgifter för privata register per arbetsflöde
• Utgående trafik, tillåtna destinationer och den utgående proxyns beteende beskrivs i CI-runners