Changer de fournisseur de runners GitHub Actions : labels, caches, secrets, facturation et fallback

Ce guide est neutre vis-à-vis des fournisseurs. Il explique ce qui change quand vous changez de fournisseur de runners GitHub Actions, ce qui casse le plus souvent et comment revenir en arrière. Nous développons CRACI, l'un de ces fournisseurs ; il apparaît là où un fait documenté s'applique, et dans une section dédiée à la fin. Pour choisir d'abord un fournisseur, consultez le comparatif des fournisseurs de runners GitHub Actions et les alternatives aux runners hébergés par GitHub.

Ce qui change et ce qui reste quand vous changez de fournisseur

GitHub Actions a deux moitiés. GitHub est le plan de contrôle : il stocke le dépôt et les fichiers de workflow, déclenche les événements, stocke les secrets, attribue les jobs, affiche les logs et les checks, conserve les artefacts et émet les tokens OIDC. Le runner CI est l'endroit où un job s'exécute : une machine avec une image, du CPU, du disque, un accès réseau à Internet et généralement un cache local. GitHub attribue un job à un runner, lui transmet les secrets du job au démarrage, et le runner renvoie les logs en continu.

Un fournisseur de runners ne remplace que la seconde moitié.

Élément	Reste chez GitHub	Passe chez le fournisseur
Dépôt, fichiers de workflow, déclencheurs	Oui	Non
Stockage des secrets	Oui	Les secrets sont transmis à la machine du fournisseur au démarrage du job
Attribution des jobs, logs, interface des checks	Oui	Le runner renvoie les logs en continu
Artefacts de actions/upload-artifact	Oui	Non
Émetteur du token OIDC	Oui	Non, mais le token indique que le runner est auto-hébergé
Machine, image, CPU, mémoire, disque	Non	Oui
Chemin réseau sortant et adresses IP	Non	Oui
Stockage du cache	Selon le fournisseur	Selon le fournisseur
Facturation à la minute des jobs déplacés	Non	Oui

Un runner tiers s'enregistre auprès de GitHub comme runner auto-hébergé. C'est pourquoi les règles de GitHub pour les runners auto-hébergés s'y appliquent : la façon dont les labels orientent les jobs, dont les groupes de runners limitent l'accès, dont le token OIDC le décrit et dont GitHub le facture.

Le changement de runs-on et les labels

GitHub cherche un runner qui correspond aux labels et groupes runs-on du job. Si aucun runner correspondant n'est en ligne, le job reste en file d'attente jusqu'à ce qu'il y en ait un ; si un runner attribué ne prend pas le job dans les 60 secondes, le job est remis en file ; et un job qui reste en file plus de 24 heures échoue (référence de GitHub sur les runners auto-hébergés). Une faute de frappe dans un label, ou une app du fournisseur non installée sur le dépôt, se traduit par un job qui ne démarre jamais.

Les fournisseurs décrivent la machine de l'une de ces deux façons :

• Dans le label. Ubicloud utilise des labels comme ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 et Avrea avrea-ubuntu-latest-2-vcpu, avec arm dans le label pour les machines ARM. Changer de taille, c'est changer de label.
• Dans une étape de setup. CRACI utilise un seul label, runs-on: craci, et l'étape cracicorp/setup@v1 sélectionne la taille (de 1 à 32 unités de calcul de 1 vCPU et 3 Go, 2 par défaut), l'image, la politique réseau ou un modèle de runner d'organisation par son slug. Si CRACI ne parvient pas à analyser une entrée, il exécute l'environnement par défaut et écrit un avertissement dans le log du job ; une image ou un modèle inconnu est rejeté.

Réduisez la bascule à une variable

Placez le label dans une variable de dépôt ou d'organisation au lieu de l'écrire en dur. Basculer dans un sens ou dans l'autre devient alors un changement de paramètre, pas une pull request dans chaque dépôt.

jobs:
  build:
    # Falls back to GitHub-hosted when the variable is not set
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: make build

  deploy:
    needs: build
    # Stays on GitHub-hosted until you decide to move it
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

Le choix se fait par job : les jobs de build et de test peuvent migrer pendant qu'un job de déploiement reste en place. Les variables peuvent être définies au niveau de l'organisation et surchargées par dépôt, si bien qu'un seul paramètre peut déplacer un groupe de dépôts et qu'un dépôt peut s'en exclure.

Workflows réutilisables

Si le même pipeline est copié dans de nombreux dépôts, placez-le dans un workflow réutilisable qui lit le runner depuis une entrée ou une variable. Changer runs-on à cet endroit change chaque dépôt qui l'appelle. Les rulesets peuvent imposer l'exécution d'un workflow sur les dépôts d'une organisation, ce qui garantit l'usage de la version partagée.

Images de runner : compatibilité et épinglage

L'image hébergée de GitHub embarque un vaste ensemble d'outils préinstallés et un tool cache hébergé. Les fournisseurs proposent soit une image compatible avec celle de GitHub, soit une image plus légère. Les jobs dépendent souvent de choses qu'ils ne déclarent jamais :

• des versions de langages et des outils en ligne de commande préinstallés ;
• sudo sans mot de passe, et systemd pour les services lancés avec systemctl ;
• un démon Docker en marche, avec Buildx et Compose ;
• le tool cache hébergé que les actions setup-* lisent avant de télécharger ;
• de l'espace disque libre pour les gros builds.

Règle de décision : commencez avec l'image compatible GitHub du fournisseur. Ne passez un job sur une image légère qu'une fois qu'il est au vert, et ajoutez des étapes setup-* explicites pour tout ce qu'il utilisait implicitement.

Épinglage : ubuntu-latest passe à une nouvelle version selon le calendrier de GitHub, et ubuntu-24.04 fige la version du système d'exploitation, pas les versions des paquets qu'il contient. Épinglez ce qui compte dans le job : les actions de setup avec des versions explicites, et les images de conteneur par digest. Demandez à chaque fournisseur ce qu'il vous permet d'épingler. L'application runner elle-même doit continuer à se mettre à jour pour dialoguer avec GitHub.

Sur CRACI, les images sont CRACI Slim sur x86-64 et ARM64 (Ubuntu 24.04, sans systemd) et une image Ubuntu 24.04 complète compatible GitHub Actions, sélectionnée avec ubuntu-24.04 ou ubuntu-latest, qui suit l'image de runner Ubuntu 24.04 de GitHub et inclut le tool cache hébergé. Chaque image contient Docker Engine, Buildx et Compose v2.

Caches : ce qui est repris et ce qui démarre à froid

Les premières exécutions chez un nouveau fournisseur sont souvent plus lentes, et la cause habituelle est un cache froid, pas une machine lente. Le fonctionnement d'actions/cache détermine ce que vous observez (README d'actions/cache) :

• Une entrée est retrouvée par sa clé et une version, qui est un hash des chemins mis en cache et de l'outil de compression.
• Les entrées sont cloisonnées par branche ; celles de la branche par défaut sont accessibles aux autres branches.
• Par défaut, un dépôt peut contenir jusqu'à 10 Go de caches avant que les entrées les plus anciennes ne soient évincées. Les administrateurs du dépôt et les propriétaires de l'organisation ou de l'entreprise peuvent relever la limite ; l'usage au-delà de 10 Go est facturé au compte (GitHub sur le dependency caching).
• Un cache enregistré sous Windows n'est pas restauré sur un autre système d'exploitation, et inversement, sauf si enableCrossOsArchive est défini ; un autre outil de compression donne aussi une autre version.

Les fournisseurs servent le cache de l'une de ces deux façons :

Modèle	Premières exécutions	Contrepartie
Le runner utilise le service de cache de GitHub, comme les runners hébergés par GitHub	Les entrées existantes sont restaurées	Le trafic du cache traverse Internet entre le fournisseur et GitHub
Le fournisseur sert l'API de cache depuis un stockage situé à côté de ses runners	Généralement vide jusqu'à ce que les premières exécutions le remplissent, sauf si le fournisseur importe les entrées de GitHub ou s'y rabat	Restaurations plus rapides ; les entrées écrites là ne sont généralement pas visibles des runners hébergés par GitHub

Ce second point compte pour les flottes mixtes et pour le retour en arrière : si vous rebasculez un job, il peut aussi démarrer à froid sur GitHub. Demandez quel modèle le fournisseur utilise et où se trouvent les entrées.

Distinguer un cache froid d'un runner lent. Prenez un build Node qui met en cache un gros répertoire node_modules. À la première exécution chez un nouveau fournisseur, actions/cache signale un miss, l'étape d'installation télécharge tout et l'étape post enregistre le cache. Dès l'exécution suivante sur la même branche, l'étape signale un hit et l'étape d'installation raccourcit. Ne comparez les exécutions qu'une fois le cache chaud : lisez la sortie cache-hit, et chronométrez l'étape de restauration et l'étape d'installation séparément du build lui-même. Consultez le fonctionnement du cache GitHub Actions pour les clés, les portées et l'empoisonnement de cache.

Sur CRACI, actions/cache fonctionne comme aujourd'hui, et l'enregistrement du build indique pour chaque paquet s'il a été restauré depuis un cache CI plutôt que téléchargé.

Cache des couches Docker

Mécanisme	Où se trouvent les couches	À savoir
BuildKit type=gha	Le cache GitHub Actions	Mêmes règles de portée et de taille que ci-dessus ; il nécessite un builder qui le prend en charge
BuildKit type=registry	Une image distincte dans votre registre	Fonctionne sur n'importe quel runner et survit à un changement de fournisseur ; vous payez le stockage et le transfert du registre
Cache de couches local au fournisseur ou disque persistant	À côté des runners du fournisseur	Généralement le plus rapide ; reste sur place si vous quittez le fournisseur

Un cache de registre est l'option portable (backends de cache Docker) :

- uses: docker/build-push-action@v7
  with:
    push: true
    tags: ghcr.io/acme/app:latest
    cache-from: type=registry,ref=ghcr.io/acme/app:buildcache
    cache-to: type=registry,ref=ghcr.io/acme/app:buildcache,mode=max

Deux jobs qui démarrent en même temps restaurent le même cache et construisent tous deux les couches manquantes. Cela se produit sur n'importe quelle CI : n'y voyez pas un problème de fournisseur.

CRACI propose le cache des couches de conteneur avec un cache de couches local, un cache de couches distant et un cache par bind mount.

Secrets, OIDC et identifiants cloud

GitHub stocke vos secrets et les transmet au runner qui exécute le job, quel qu'il soit. Déplacer un job chez un fournisseur, c'est confier à ce fournisseur les secrets de ce job. Demandez :

• Chaque job dispose-t-il de sa propre machine virtuelle, ou d'un conteneur sur un hôte partagé ?
• La machine est-elle détruite après le job, et quelque chose est-il conservé ?
• Quels logs le fournisseur conserve-t-il ? GitHub masque les secrets enregistrés dans les logs des jobs, et précise que le masquage automatique n'est pas garanti pour les valeurs transformées ; renseignez-vous aussi sur les logs système du fournisseur.

OIDC continue de fonctionner, avec un piège. C'est GitHub qui émet le token OIDC, pas le runner : permissions: id-token: write fonctionne donc sur n'importe quel runner. Mais le claim runner_environment du token vaut github-hosted ou self-hosted (référence OIDC de GitHub), et sur un runner tiers il vaut self-hosted. Une politique de confiance cloud qui exige github-hosted rejette le job. Par exemple, un workload identity pool Google Cloud avec cette condition d'attribut :

# Before: only GitHub-hosted runners in the acme organization
assertion.repository_owner == 'acme' && assertion.runner_environment == 'github-hosted'

# After: drop the runner check, and narrow by repository and branch instead
assertion.repository == 'acme/app' && assertion.ref == 'refs/heads/main'

Supprimer la vérification du runner élargit le cercle de ceux qui peuvent obtenir des identifiants : resserrez donc une autre condition en même temps. Avant la bascule, recherchez runner_environment dans chaque politique de confiance cloud et chaque configuration de workload identity.

Push d'images : GITHUB_TOKEN avec packages: write pousse vers GitHub Container Registry depuis n'importe quel runner, et les connexions aux registres qui utilisent des secrets stockés fonctionnent sans changement.

Sur CRACI, la GitHub App lit votre code et vos exécutions Actions et gère les runners qu'elle enregistre pour votre organisation. Chaque job s'exécute dans sa propre machine virtuelle isolée, et CRACI ne stocke pas votre code source.

Identité réseau : listes d'autorisation IP et trafic sortant

Le nouveau runner sort par de nouvelles adresses IP. Recensez tout ce qui filtre par adresse source :

• les listes d'autorisation des bases de données et des dépôts d'artefacts ;
• les API SaaS avec restrictions IP ;
• les serveurs SFTP de partenaires et les services internes derrière un pare-feu.

Les options sont les adresses IP sortantes statiques ou stables du fournisseur, ou un proxy que vous contrôlez. C'est aussi le moment de décider ce que les jobs ont le droit d'atteindre : une politique de trafic sortant sur le runner empêche une dépendance compromise d'envoyer des secrets vers un hôte dont le build n'a jamais eu besoin. Consultez la politique de trafic sortant GitHub Actions.

CRACI propose une plage d'adresses IP sortantes stable et une politique de trafic sortant, en refus ou en autorisation par défaut, validée avant le démarrage du job et qui bloque tout en cas d'échec. Sans entrée network, le modèle par défaut autorise les autres connexions sortantes : le contrôle du trafic sortant est donc à configurer.

Flottes mixtes : migrer Linux, garder macOS et iOS là où ils sont

Le runner se choisit par job : un même workflow peut exécuter ses jobs Linux chez un fournisseur et ses jobs macOS sur des runners hébergés par GitHub. Les artefacts envoyés avec actions/upload-artifact sont stockés par GitHub, si bien qu'un job sur un runner peut transmettre des fichiers à un job sur un autre.

jobs:
  backend:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew test

  android:
    runs-on: ${{ vars.LINUX_RUNNER || 'ubuntu-latest' }}
    steps:
      - uses: actions/checkout@v7
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v7
        with:
          name: android
          path: app/build/outputs/apk/release/

  ios:
    # Signing and the iOS build stay on GitHub-hosted macOS
    runs-on: macos-latest
    needs: backend
    steps:
      - uses: actions/checkout@v7
      - run: xcodebuild -scheme App -configuration Release archive

Les jobs restés sur GitHub consomment toujours l'usage inclus dans votre plan et sont facturés par GitHub au-delà. CRACI exécute aujourd'hui Linux sur x86-64 et ARM64, avec Windows et macOS sur la feuille de route : une flotte mixte avec CRACI signifie donc CRACI pour Linux et des runners hébergés par GitHub pour le reste.

Fallback quand un fournisseur est indisponible

GitHub n'a pas de fallback intégré entre labels de runners. Si aucun runner correspondant au label n'est en ligne, le job attend, et au bout de 24 heures il échoue. Anticipez :

• La bascule par variable ci-dessus : remettez-la sur ubuntu-latest et les nouvelles exécutions partent sur des runners hébergés par GitHub.
• Une surcharge manuelle pour les exécutions urgentes : une entrée workflow_dispatch, lue sous la forme runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes sur les jobs, pour qu'un job bloqué ne retienne pas un déploiement pendant des heures.
• Une surveillance du temps d'attente, pour remarquer quand les jobs attendent plus longtemps que d'habitude.

Demandez à chaque fournisseur s'il propose un fallback automatique et ce qui le déclenche. Prévoyez aussi le cas inverse : GitHub met en file et attribue chaque job, donc une panne de GitHub Actions arrête aussi les jobs chez tous les fournisseurs de runners.

Facturation : GitHub facture-t-il encore ?

GitHub ne facture pas à la minute les runners auto-hébergés, et les runners tiers s'enregistrent comme auto-hébergés : les minutes que vous déplacez disparaissent donc de la facture GitHub (facturation de GitHub Actions). GitHub facture toujours :

• les sièges de votre plan ;
• le stockage des artefacts et du cache qu'il conserve au-delà du quota inclus ;
• les jobs restés sur des runners hébergés par GitHub, au-delà de l'usage inclus dans votre plan, qui n'est pas remboursé.

Pendant le pilote, vous payez deux factures. Les fournisseurs comptent les minutes de build différemment : GitHub arrondit chaque job à la minute supérieure, et certains fournisseurs mesurent à la seconde. Pour évaluer votre consommation avant et après, utilisez le calculateur de coûts GitHub Actions. CRACI ne facture que les minutes de build : $0.002 par minute vCPU ($0.004 pour un runner par défaut à 2 vCPU), mesurées à la seconde, sans frais mensuels.

Isolation de sécurité : les questions à poser à tout fournisseur

Question	Pourquoi c'est important
Une machine virtuelle par job, ou des conteneurs sur un hôte partagé ?	Un hôte partagé permet à un job compromis d'atteindre ses voisins
La machine est-elle détruite après le job ?	Une machine persistante transmet fichiers, identifiants et processus au job suivant
Où se trouve le matériel, et qui l'exploite ?	Localisation des données, juridiction et contrats de vos clients
Que stocke le fournisseur, et pendant combien de temps ?	Les logs, les caches et les données réseau peuvent contenir des éléments sensibles
Quelles certifications détient-il ?	Votre évaluation fournisseur le demandera
Pouvez-vous contrôler le trafic sortant ?	Empêche les secrets de sortir via un paquet malveillant
Que peut lire et modifier sa GitHub App ?	Les permissions de l'app s'appliquent à chaque dépôt sur lequel vous l'installez

GitHub indique que les runners auto-hébergés ne devraient presque jamais être utilisés pour des dépôts publics, car n'importe qui peut ouvrir une pull request et compromettre l'environnement, et que les runners just-in-time exécutent au plus un job avant d'être supprimés (référence de GitHub sur l'usage sécurisé). Une machine virtuelle neuve par job répond à l'essentiel de cette préoccupation.

Les réponses de CRACI : chaque job s'exécute dans sa propre machine virtuelle isolée, sur une infrastructure bare-metal européenne. Le système de management de la sécurité de l'information de CRACI Corporation Oy, pour le développement et l'exploitation de la plateforme CRACI, est certifié ISO/IEC 27001 par Into Certification, avec les détails dans le Trust Center. CRACI stocke les métadonnées de build, les données de paquets, les traces réseau, les SBOM, la provenance, les caches et les enregistrements d'audit, et jamais votre code source. Consultez ce à quoi CRACI peut accéder et la sécurité.

Testez d'abord sur un seul dépôt

1. Choisissez un dépôt avec un workflow Linux représentatif et fréquemment exécuté, pas le pipeline de release.
2. Établissez une référence sur les runners hébergés par GitHub : durée et temps d'attente médians sur les 30 dernières exécutions, et minutes facturées.
3. Installez la GitHub App du fournisseur sur ce dépôt uniquement.
4. Basculez un job via la variable de dépôt, sur une branche.
5. Lancez-le au moins dix fois, et écartez les trois premières exécutions, qui servent à chauffer le cache.
6. Comparez la durée, le temps d'attente, le taux de hits de cache, les échecs et le coût ; vérifiez les logs, OIDC et les appels sortants.
7. Revenez en arrière en changeant la variable, et vérifiez que le job retourne sur les runners hébergés par GitHub.

Indicateur	Référence hébergée par GitHub	Fournisseur	Seuil de réussite
Durée médiane des jobs			Votre objectif, par exemple 30 % plus court
Temps d'attente médian			Pas pire que la référence
Taux de hits de cache après chauffe			Identique à la référence
Exécutions échouées sans lien avec le code			Aucune
Coût par exécution			Inférieur à la référence
OIDC, listes d'autorisation et appels sortants			Tout fonctionne

Mesurez la vitesse sur votre propre workflow. Chaque fournisseur publie ses propres chiffres, et le seul qui tranche dans votre cas est celui de votre pipeline.

La place de CRACI

CRACI est un runner GitHub Actions. Il remplace le runner, pas GitHub Actions : un job migre avec runs-on: craci, les tailles et les images se règlent avec cracicorp/setup@v1 ou un modèle de runner d'organisation, et les exécutions apparaissent toujours dans GitHub. CRACI exécute les builds environ deux fois plus vite que les runners hébergés par GitHub, grâce à un matériel plus rapide, des temps d'attente plus courts et la mise en cache.

Ce qui le distingue des autres fournisseurs, c'est ce que chaque job laisse derrière lui : une SBOM de ce que le build a récupéré, avec un état de complétude, enregistrée sous une politique de trafic sortant qui bloque tout en cas d'échec. docs.craci.com propose aussi un prompt pour agents de code qui suggère un plan de migration job par job pour vos workflows. Consultez l'intégration CI/CD.

Quand CRACI n'est pas la bonne réponse

• Vous avez besoin de runners macOS ou Windows : ils sont sur la feuille de route de CRACI.
• Vous utilisez GitHub Enterprise Server, que CRACI ne prend pas en charge.
• Votre CI est GitLab CI ou Jenkins : les deux sont sur la feuille de route.
• Les runners doivent tourner dans votre propre compte cloud : les runners hébergés par le client sont sur la feuille de route. RunsOn et l'option bring-your-own-cloud de WarpBuild le font dès aujourd'hui ; consultez CRACI vs RunsOn et CRACI vs WarpBuild.
• Votre objectif principal est l'observabilité et le débogage de la CI ; consultez CRACI vs Avrea. Pour exploiter vos propres runners, consultez runners managés ou auto-hébergés.

Changer de fournisseur de runners : questions fréquentes

Que faut-il changer pour utiliser un autre fournisseur de runners GitHub Actions ?

Installez la GitHub App du fournisseur, puis remplacez le label runs-on du job par celui du fournisseur. Les workflows, les déclencheurs, les secrets et l'interface GitHub restent les mêmes. Avant de déplacer des jobs importants, vérifiez l'image du runner, les caches, les adresses IP sortantes, les politiques de confiance cloud qui utilisent OIDC, le fallback et la facturation.

Mes caches GitHub Actions sont-ils repris chez un nouveau fournisseur de runners ?

Cela dépend de l'endroit d'où le fournisseur sert le cache. Si ses runners utilisent le service de cache de GitHub, les entrées existantes sont restaurées. S'il sert l'API de cache depuis un stockage situé à côté de ses runners, le cache démarre généralement vide et se remplit lors des premières exécutions. Demandez au fournisseur quel modèle il utilise, et si les entrées écrites sur ses runners sont visibles des runners hébergés par GitHub.

Le cache des couches Docker fonctionne-t-il sur des runners tiers ?

Oui, avec l'un de ces trois mécanismes : le backend type=gha de BuildKit, qui utilise le cache Actions ; un cache de registre avec type=registry, qui fonctionne sur n'importe quel runner ; ou un cache de couches ou un disque persistant que le fournisseur conserve à côté de ses runners.

Puis-je garder les builds macOS et iOS sur GitHub pendant que les jobs Linux migrent ?

Oui. Le runner se choisit par job : les jobs Linux peuvent tourner chez un fournisseur pendant que les jobs macOS restent sur des runners hébergés par GitHub, dans le même workflow. Reliez-les avec needs: et transmettez les fichiers avec actions/upload-artifact et actions/download-artifact, que GitHub stocke.

Que devient un job si le runner tiers est indisponible ? Existe-t-il un fallback ?

GitHub n'a pas de fallback intégré entre labels de runners. Un job dont le label ne correspond à aucun runner en ligne reste en file d'attente et échoue au bout de 24 heures. Placez le label dans une variable de dépôt ou d'organisation pour que le retour en arrière tienne en un seul changement, définissez timeout-minutes, et demandez à chaque fournisseur s'il propose son propre fallback.

Les secrets et OIDC fonctionnent-ils toujours sur des runners tiers ?

Oui. GitHub stocke les secrets et les transmet au runner au démarrage du job, et c'est GitHub qui émet le token OIDC : id-token: write fonctionne donc sur n'importe quel runner. Le piège : sur un runner tiers, le claim runner_environment du token vaut self-hosted, si bien qu'une politique de confiance cloud qui exige github-hosted rejette le job.

GitHub me facture-t-il encore des minutes si j'utilise un autre fournisseur de runners ?

Pas pour les jobs que vous déplacez. Les runners tiers s'enregistrent auprès de GitHub comme runners auto-hébergés, et GitHub indique que les runners auto-hébergés ne sont pas facturés à la minute. GitHub facture toujours les sièges, le stockage qu'il conserve au-delà du quota inclus et les jobs restés sur des runners hébergés par GitHub. Le fournisseur facture ses propres minutes.

Comment épingler l'image du runner pour qu'elle ne change pas à mon insu ?

ubuntu-latest évolue selon le calendrier de GitHub, et ubuntu-24.04 fige la version du système d'exploitation, mais pas les versions des paquets qu'il contient. Épinglez ce qui compte dans le job : les actions de setup avec des versions explicites, et les images de conteneur par digest. Demandez à chaque fournisseur ce qu'il vous permet d'épingler ; l'application runner elle-même doit se mettre à jour pour continuer à fonctionner avec GitHub.

Comment les jobs sont-ils isolés les uns des autres sur un runner tiers ?

Cela varie selon les fournisseurs. Demandez si chaque job dispose de sa propre machine virtuelle ou d'un conteneur sur un hôte partagé, si la machine est détruite après le job, et ce que le fournisseur conserve ensuite. Une machine virtuelle neuve par job est le plus solide des modèles courants, car rien d'un job ne reste pour le suivant.

Comment tester d'abord un fournisseur de runners sur un seul dépôt ?

Installez la GitHub App du fournisseur sur un seul dépôt, basculez un job Linux fréquemment exécuté via une variable de dépôt sur une branche, lancez-le au moins dix fois, et comparez la durée, le temps d'attente, les hits de cache, les échecs et le coût à une référence sur runners hébergés par GitHub. Revenez en arrière en changeant la variable.