Caches de paquets

fremforge ne fait plus tourner de caches partagés distincts pour les runners hébergés. Le cache est le proxy de dépendances propre à votre organisation, dans la même région de l’UE que les VM des runners. Lorsque le pull-through des runners (runner pull-through) est activé, ce qui est le cas par défaut pour toute organisation n’ayant pas enregistré ses propres réglages de proxy de dépendances, chaque job est dirigé vers lui à son démarrage (voir Hosted runners) :

Chaque repli passe par le proxy de sortie de fremforge dans l’UE pour atteindre le registre public. Le proxy est vérifié au début de chaque job ; s’il est injoignable, le job utilise les registres publics et le repli est journalisé.

Le proxy tourne dans la même région OTC que les VM des runners (eu-de, Allemagne). Un élément absent du cache est récupéré en amont via la sortie de fremforge, puis mis en cache pour le prochain workflow de votre organisation.

Pourquoi c’est automatique

Une installation de dépendances classique télécharge des dizaines de mégaoctets de paquets à chaque build. Sans cache, ce trafic traverse la passerelle NAT et sollicite l’index public à chaque fois. Avec un cache, les paquets déjà présents proviennent d’un stockage interne à la région.

Vous n’avez rien à configurer : chaque outil applique automatiquement son réglage. yarn et bun ne sont pas dirigés vers le proxy ; ils installent depuis registry.npmjs.org via le proxy de sortie de fremforge.

Remplacement par workflow

Pour remplacer ce comportement (par ex. si vous devez récupérer des paquets depuis un registre privé), définissez la variable dans l’env de votre workflow :

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

Un env: au niveau de l’étape est aussi pris en compte. Votre réglage l’emporte toujours sur la valeur par défaut de fremforge.

pnpm 11 ne lit pas NPM_CONFIG_REGISTRY : définissez aussi PNPM_CONFIG_REGISTRY avec la même URL, sinon pnpm 11 continue d’installer depuis registry.npmjs.org.

Images de conteneurs

Lorsque le pull-through des runners est activé, le démon Docker du job récupère les images de conteneurs via le proxy de dépendances de votre organisation, et elles sont mises en cache pour votre organisation : docker pull, docker run, le FROM d’un Dockerfile, ainsi que les conteneurs du job et de services:. Les noms d’images restent inchangés. Cela couvre ghcr.io, quay.io, mcr.microsoft.com, registry.k8s.io, public.ecr.aws et registry.access.redhat.com pour toutes les organisations. Si le proxy est injoignable, ou ne peut pas servir une récupération, l’image est récupérée directement depuis le registre. Pour les images, le proxy est un cache, pas un point de contrôle. Un builder docker buildx utilisant le pilote docker-container récupère les images directement. Les détails sont dans Hosted runners.

Images Docker Hub

Il n’y a pas de miroir Docker Hub partagé, et DOCKER_MIRROR_URL n’est plus défini. Docker Hub (docker.io), comme registry.redhat.io et registry.connect.redhat.com, ne passe par votre proxy qu’avec l’identifiant propre à votre organisation. Sans identifiant, un docker pull ou un FROM d’une image Docker Hub dans un workflow est une récupération anonyme directement depuis Docker Hub, soumise à la limite de débit de Docker Hub pour les récupérations anonymes.

Dès qu’un propriétaire enregistre le jeton Docker Hub de votre organisation dans le proxy de dépendances, les récupérations Docker Hub de vos jobs passent par le proxy et sont mises en cache, sauf dans les jobs issus de pull requests provenant de forks. Vous pouvez aussi passer explicitement par frem.sh/<org>/dependency-proxy/docker.io/. Consultez Pull Docker Hub images through the dependency proxy with your own Docker Hub token.

npm audit et pnpm audit via le proxy de dépendances

npm audit et pnpm audit envoient leur requête d’audit au registre depuis lequel ils installent. Lorsque ce registre est le proxy de dépendances de votre organisation (https://frem.sh/_app/proxy/<org>/npm/), comme c’est le cas pour les jobs où le pull-through des runners est activé, le proxy répond lui-même à la requête, au format bulk-advisory de npm, à partir de l’index d’avis de sécurité propre à fremforge, construit à partir des données OSV. Le corps de la requête est la liste exacte de vos dépendances, et le proxy ne la transmet pas : elle n’atteint jamais registry.npmjs.org ni aucun autre service tiers d’avis de sécurité. La requête est authentifiée comme toute autre requête au proxy, avec un jeton frem.sh autorisé à lire les paquets de l’organisation.

• Clients pris en charge : npm 7 et versions ultérieures, et pnpm 11 et versions ultérieures. Tous deux envoient POST /-/npm/v1/security/advisories/bulk, le seul point de terminaison d’audit que sert le proxy. Le corps peut être compressé en gzip, jusqu’à 4 Mio.
• Non pris en charge : npm 6 et pnpm 10 ou antérieur utilisent les anciens points de terminaison d’audit (/-/npm/v1/security/audits et /-/npm/v1/security/audits/quick), auxquels le proxy répond 404. Utilisez npm 7 ou ultérieur ou pnpm 11, ou passez --ignore-registry-errors à pnpm.
• pnpm 11 ne lit pas NPM_CONFIG_REGISTRY. Il prend son registre dans PNPM_CONFIG_REGISTRY, un .npmrc ou pnpm-workspace.yaml. Le pull-through des runners désigne le proxy dans le npmrc du job, que pnpm 11 lit. Si vous dirigez vous-même un job vers le proxy avec NPM_CONFIG_REGISTRY, définissez PNPM_CONFIG_REGISTRY avec la même URL, sinon pnpm 11 installe depuis registry.npmjs.org et y envoie son audit.
• Si l’index d’avis de sécurité ne peut pas être lu, le proxy répond 503 avec Retry-After: 10 au lieu d’un rapport vide : une consultation qui échoue fait donc échouer l’audit au lieu de se lire comme « aucune vulnérabilité ».
• Dans le rapport, les URL des avis pointent vers osv.dev, et chaque titre se termine par l’identifiant OSV (par exemple un identifiant GHSA). Une version connue pour être malveillante est signalée comme Malicious package (MAL-…). L’id numérique de l’avis qu’affiche npm est dérivé de l’identifiant OSV.

Ce qui n’est PAS mis en cache

• Les paquets privés. Le proxy récupère anonymement npm, PyPI, Go, Maven, NuGet et les autres registres de paquets : il ne sert donc que des paquets publics, et l’en-tête Authorization de votre job n’est jamais transmis en amont. Les images privées ghcr.io et quay.io, ainsi que Docker Hub et les registres Red Hat, utilisent l’identifiant amont propre à votre organisation. Pour un registre de paquets privé, remplacez la variable concernée (NPM_CONFIG_REGISTRY, PIP_INDEX_URL, GOPROXY, …).
• Les appels d’API dynamiques. Les appels d’API de type GitHub (par ex. npm view <package> sur api.npmjs.org) ne sont pas mis en cache ; seuls les points de terminaison de données de paquets des registres le sont.
• Les dépôts de sources. Le trafic git clone vers GitHub / GitLab / votre propre forge n’est pas mis en cache. Utilisez le registre de paquets de fremforge (https://frem.sh/api/packages/<org>/<type>/) lorsque vous maîtrisez la source.
• Les images de conteneurs d’autres registres. Les images provenant de registres que le proxy de dépendances ne connaît pas (gcr.io, un registre privé) sont récupérées directement. Docker Hub et les registres Red Hat ne sont mis en cache qu’avec l’identifiant propre à votre organisation ; voir Images Docker Hub. Configurez un registre privé directement dans chaque workflow.

Performances attendues

• Cache froid (première récupération d’une nouvelle version de paquet) : ~2 à 5 s de plus qu’en amont ; le cache récupère le paquet en amont, l’enregistre dans OBS, puis le renvoie. Latence nette = récupération en amont + écriture dans OBS.
• Cache chaud (récupérations suivantes de la même version) : ~30 à 60 s de moins qu’en amont pour une exécution npm ci classique ; le cache sert depuis OBS, au sein de la région.
• Durée de conservation : votre réglage de rétention, 90 jours par défaut. Un fichier en cache qui n’a pas été récupéré pendant cette durée est supprimé ; les versions de paquets et les images de base que votre organisation utilise encore sont conservées. Voir Retention.

Souveraineté

Le proxy de dépendances tourne dans le cluster eu-de de fremforge, et son stockage est un bucket OBS en eu-de. C’est un logiciel propre à fremforge, construit et déployé comme le reste de la plateforme. Les récupérations en amont sont anonymes, sauf si votre organisation a enregistré son propre identifiant pour cet amont (par exemple Docker Hub) ; voir Upstream credentials.

Ce que reçoivent les registres amont est décrit sous What the upstream sees. Chaque récupération est consignée dans le journal d’accès au registre de votre organisation (pour les accès au cache depuis la CI, dans le recensement des récupérations). Le DPA couvre les deux : le journal d’accès à l’annexe A.6, et les registres amont, choisis sur votre instruction et qui ne sont pas des sous-traitants ultérieurs, à l’annexe B §B.9.

État du service et réponse aux incidents

Le proxy de dépendances est surveillé. Chaque job le vérifie à son démarrage : s’il est injoignable, ce job installe et récupère depuis les registres publics via la sortie de fremforge, et le repli est journalisé. Impact attendu : ~30 à 60 s de plus par récupération non mise en cache. Un proxy qui tombe en panne au milieu d’un job n’est pas contourné : npm et pnpm font de nouvelles tentatives, et un proxy surchargé répond 503 avec Retry-After (voir Errors).

Voir aussi

• Image de runner : ce qui est intégré à l’image de runner hébergé (kaniko, buildkit, chaînes d’outils des langages)
• Secrets : comment injecter des identifiants de registres privés par workflow
• La sortie réseau, les destinations autorisées et le comportement du proxy de sortie sont traités dans Runners CI