Image du runner hébergé

Les workflows qui ciblent runs-on: fremforge s’exécutent sur une VM éphémère, une par commit, provisionnée à partir de l’image du runner hébergé. Celle-ci est conçue pour la parité avec ubuntu-latest : la même expérience actions/setup-* que sur GitHub Actions, les mêmes chaînes d’outils intégrées, les mêmes scanners, plus Docker natif pour les builds de conteneurs.

Architecture en deux couches

L’image de runner est le disque de démarrage de la VM : les deux couches sont livrées sur le même disque et présentes dès le démarrage de la VM, sans aucun téléchargement par job.

Les actions setup-* se résolvent depuis le hostedtoolcache, sans téléchargement par job. RUNNER_TOOL_CACHE et AGENT_TOOLSDIRECTORY pointent déjà vers /opt/hostedtoolcache.

Les numéros de version des tableaux ci-dessous indiquent quelles lignes majeures/mineures sont intégrées. Les versions exactes résolues sont mises à jour en continu par la reconstruction hebdomadaire et publiées automatiquement à chaque reconstruction ; consultez le changelog pour la pile d’outils publiée actuelle.

Langages : système

Une seule version récente dans le PATH. Utilisez-les directement si la version système par défaut convient à votre workflow.

Langages : plusieurs versions via les actions setup-*

Utilisez ces actions actions/setup-* exactement comme sur les runners hébergés par GitHub. La version demandée se résout depuis le hostedtoolcache (aucune récupération réseau).

Si vous avez besoin d’une version que nous n’intégrons pas (par ex. Node 20.x pour un projet ancien), actions/setup-node, actions/setup-go, actions/setup-java et actions/setup-dotnet peuvent télécharger une version non intégrée au moment du job (plus lent, mais cela fonctionne : elles récupèrent des builds Linux génériques). actions/setup-python et ruby/setup-ruby ne le peuvent pas : l’amont ne publie de build debian pour aucune des deux, si bien qu’une série non intégrée échoue purement et simplement au lieu de se replier. Choisissez une série intégrée, ou utilisez uv python install <version> (uv est intégré) ou un job container: pour un besoin ponctuel.

Outils de compilation essentiels

Les modules Node natifs, les wheels Python avec extensions C, cgo pour Go et les crates Rust avec dépendances C se compilent sans configuration supplémentaire.

build-essential (gcc + make) · clang + lld · cmake · ninja · pkg-config · autoconf · automake · libtool · zstd · linux-headers (via la base)

Gestionnaires de paquets et outillage de projet

Versions de pnpm et de Yarn

pnpm et yarn passent par corepack, qui est activé sur le runner. La version qu’obtient un job dépend de l’épinglage éventuel d’une version par le projet :

• Pas d’épinglage : un job obtient pnpm 12.14.0 et Yarn 4.18.1. Les deux sont présents sur le runner, aucun téléchargement n’est donc nécessaire. Jusqu’au 2026-10-21, un job sans épinglage obtenait la version latest de npm au moment de son exécution, ce qui, pour Yarn, correspondait à Yarn Classic 1.22.
• Épinglage : définissez packageManager dans votre package.json, par exemple "packageManager": "pnpm@11.28.6" ou "packageManager": "yarn@1.22.22", et corepack exécute exactement cette version. pnpm 12.14.0 et 11.28.6 sont déjà sur le runner ; toute autre version est téléchargée au démarrage du job.

Épingler packageManager est la façon de choisir. Cela garde aussi votre machine locale et la CI sur la même version. Quand nous faisons passer les valeurs par défaut à une version plus récente, le changement est annoncé dans le changelog.

IaC

CLI cloud

Conteneurs et Kubernetes

Sécurité et chaîne d’approvisionnement

Intégrés d’avance, pour que les analyses de secrets, de CVE, de SBOM et SAST n’ajoutent aucun temps de configuration.

Linters

shellcheck · shfmt · yamllint · actionlint (analyse les workflows Forgejo Actions que vous écrivez sur frem.sh) · hadolint (Dockerfile)

Navigateurs et tests de bout en bout

Pour les tests de navigateur headless :

• Chromium + chromedriver (paquets debian, versions accordées)
• Firefox ESR + geckodriver
• Selenium Server (jar dans /opt/selenium-server.jar)

Microsoft Edge n’est pas intégré : Chromium utilise le même moteur Blink ; pour les tests en CI, Chromium est équivalent.

Clients de bases de données

postgresql-client · default-mysql-client · sqlite3. Les serveurs de bases de données complets s’obtiennent via des blocs services: (un docker pull depuis Docker Hub, via le proxy de dépendances de votre organisation lorsqu’elle dispose de son propre identifiant Docker Hub ; voir Images Docker Hub).

Mobile et data science (intégrés depuis le 2026-06-06)

# Android example
- uses: android-actions/setup-android@v3
- run: ./gradlew assembleDebug

# R example
- uses: r-lib/actions/setup-r@v2
- uses: r-lib/actions/setup-r-dependencies@v2
- run: Rscript -e 'testthat::test_local()'

# Miniconda example
- uses: conda-incubator/setup-miniconda@v3
  with:
    environment-file: env.yml
- shell: bash -el {0}
  run: pytest

Ce qui n’est toujours PAS intégré

Des outils vraiment spécialisés ou lourds dont la plupart des workflows n’ont pas besoin. Installez-les dans chaque job :

Builds de conteneurs

Docker natif (par défaut)

La VM est livrée avec le démon Docker installé et en cours d’exécution sur l’hôte. Votre CLI docker communique avec lui via le socket local standard : pas de Docker-in-Docker, pas de sidecar, pas d’indirection par DOCKER_HOST. La plupart des workflows conçus pour les runners hébergés par GitHub fonctionnent sans modification : docker build, docker compose, docker pull, builds multi-étapes, fonctionnalités BuildKit.

- run: docker build -t myapp:${{ github.sha }} .
- run: docker compose up -d
- run: docker pull postgres:16

kaniko

Pour les builds d’images seules, kaniko fonctionne sans démon (démarrage à froid plus rapide quand vous n’avez pas besoin de tout le démon Docker) et gère mieux le cache des couches avec les registres distants.

- run: |
    /usr/local/bin/kaniko \
      --context=$GITHUB_WORKSPACE \
      --dockerfile=Dockerfile \
      --destination=registry.example.com/$GITHUB_REPOSITORY:$GITHUB_SHA

Docker privilégié (imbrication KVM)

Si votre charge de travail a besoin de capacités supplémentaires au-delà de celles de l’utilisateur Docker par défaut (par ex. kind avec imbrication KVM, fonctionnalités de testcontainers nécessitant des capacités de création d’espaces de noms, accès à /dev pour des invités imbriqués), ajoutez le libellé à runs-on :

jobs:
  integration:
    runs-on: [fremforge, dind-privileged]
    steps:
      - run: docker run --privileged kindest/node:v1.31.0 ...

fremforge dirige ces jobs vers un type de VM sur lequel la virtualisation imbriquée est activée, avec la même isolation par VM et par commit que les runners par défaut.

Comment nous offrons cette couverture en ~7 Go quand les runners hébergés par GitHub font ~50 Go

Les images ubuntu-latest hébergées par GitHub sont volumineuses parce qu’elles intègrent :

1. Plusieurs versions par langage : nous intégrons les 3 séries prises en charge les plus récentes pour Node, Python, Java et Ruby, et 2 pour Go et .NET (~3 Go au total pour les 6 familles de langages). Les tableaux ci-dessus sont tenus à jour à la main et indiquent les séries, pas les versions correctives. Pour les versions correctives exactes actuellement intégrées, générées à partir des arguments de build de l’image de runner à chaque modification, consultez la liste générée de la pile d’outils. En cas de désaccord entre les deux, c’est la liste générée qui fait foi. Une série non intégrée ne peut PAS être téléchargée par job pour Python ou Ruby (voir la remarque ci-dessus) : choisissez donc parmi les séries intégrées.
2. Android SDK + NDK (~10 Go sur les runners hébergés par GitHub) : nous intégrons le SDK de base (cmdline-tools + plateforme 34 + build-tools 34.0.0 + platform-tools, ~3 Go). Les niveaux d’API supplémentaires, le NDK et les images système d’émulateurs s’installent par job via setup-android (qui réutilise ce qui est préinstallé).
3. Images de conteneurs de services Docker prérécupérées (postgres, mysql, mongo, redis, mssql, ~5 Go) : non intégrées. Un docker pull les récupère depuis Docker Hub, ou via le proxy de dépendances de votre organisation (voir caches de paquets).
4. Navigateur Microsoft Edge : non intégré (Chromium utilise le même moteur pour les besoins des tests en CI).
5. Mono / Julia / Swift / Haskell / Lua / Crystal / Nim / Elixir : non intégrés (spécialisés, à installer par job).
6. Anciennes versions de GCC, chaînes d’outils obsolètes : nous livrons un seul ensemble à jour.

Ce que nous ne perdons pas par rapport aux runners hébergés par GitHub pour les workflows courants :

• Tous les langages courants (Node, Python, Go, Java, .NET, Ruby, Rust, PHP, PowerShell)
• Le mobile (Android SDK) et la data science (Miniconda + R), intégrés depuis le 2026-06-06
• Toutes les grandes CLI cloud (AWS, Azure, GCP)
• Tous les scanners courants (Trivy, Gitleaks, OSV, Cosign, Syft, OpenGrep, Scorecard, Checkov)
• Les deux principaux navigateurs + Selenium
• Docker (natif, et privilégié via un libellé)
• Toutes les GitHub Actions standard (actions/checkout, actions/setup-*, actions/upload-artifact, etc.)

Si votre équipe a besoin d’un outil que nous n’intégrons pas, contactez le support : les outils suivis par Renovate sont intégrés à la reconstruction hebdomadaire suivante.

Taille de l’image, démarrage à froid, cadence de reconstruction

• Reconstruction hebdomadaire : chaque lundi à 06:00 UTC. Renovate propose des mises à jour de versions en continu ; la reconstruction du lundi intègre tout ce qui a été fusionné dans la semaine.
• Contrôle Trivy au moment du build : les CVE HIGH et CRITICAL font échouer le build. Nous ne livrons jamais une image comportant des résultats HIGH/CRITICAL connus et non corrigés.
• Téléchargements épinglés par sha256 : chaque binaire récupéré au moment du build est vérifié par rapport à un sha256 épinglé. Renovate met à jour la version et l’empreinte dans la même pull request. Le build échoue bruyamment en cas de dérive de l’empreinte : c’est le filet de sécurité de la chaîne d’approvisionnement.
• Démarrage à froid de la VM : ~25 s (provisionnement ECS + démarrage depuis l’image intégrée). Les VM du pool chaud (provisionnées d’avance, en attente) réduisent l’attente à ~5 s lorsque le pool a de la capacité.
• Publication du manifeste : chaque reconstruction publie les versions d’outils résolues, le condensat de l’image, le résumé Trivy et le SBOM CycloneDX dans le changelog.

Exemple de workflow

Un workflow minimal qui « utilise tout » :

name: ci

on:
  push:
    branches: [main]
  workflow_dispatch: {}

jobs:
  build-test-scan:
    runs-on: fremforge
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '24'           # resolves from hostedtoolcache, ~1 s
      - run: npm ci && npm test

      - uses: actions/setup-python@v5
        with:
          python-version: '3.13'
      - run: pip install -r requirements.txt && pytest

      - name: SAST + secrets
        run: |
          gitleaks detect --no-banner --redact
          # one --config per language folder; /opt/sast-rules itself is not a rule set
          opengrep scan --config=/opt/sast-rules/python --config=/opt/sast-rules/javascript .

      - name: SBOM
        run: syft scan dir:. -o cyclonedx-json > sbom.json

      - name: Container build
        run: docker build -t myapp:${{ github.sha }} .

Licences et mentions tierces

L’image contient des logiciels tiers sous leurs propres licences, parmi lesquels opengrep (LGPL-2.1, avec une offre de code source), Node.js et les règles SAST. Les mentions, l’attribution des données d’avis de sécurité et les endroits où obtenir le code source se trouvent sur Mentions tierces de l’image de runner. Dans un job, les fichiers de licence se trouvent sous /usr/share/licenses/ et /usr/share/doc/<package>/copyright.

Signaler un problème avec l’image de runner

Si un outil attendu n’est pas disponible, ou si vous rencontrez un problème d’exécution de la VM (limites de ressources, réseau, capacités), contactez support@frem.sh. Nous répondons le jour ouvré même pour les régressions des runners hébergés.