Slik bytter du runnerleverandør for GitHub Actions: etiketter, cacher, hemmeligheter, fakturering og fallback

Denne guiden er leverandørnøytral. Den forklarer hva som flyttes når du bytter runnerleverandør for GitHub Actions, hva som oftest går i stykker, og hvordan du går tilbake. Vi lager CRACI, en av leverandørene; den nevnes der et dokumentert faktum gjelder, og i en egen seksjon til slutt. For å velge leverandør først, se runnerleverandører for GitHub Actions sammenlignet og alternativer til GitHub-hostede runnere.

Hva som endres og hva som blir igjen når du bytter

GitHub Actions har to halvdeler. GitHub er kontrollplanet: Det lagrer repositoriet og workflow-filene, utløser triggerne, lagrer hemmeligheter, tildeler jobber, viser logger og sjekker, tar vare på artefakter og utsteder OIDC-tokener. CI-runneren er der en jobb kjører: en maskin med et image, CPU, disk, en nettverksvei til internett og vanligvis en lokal cache. GitHub tildeler en jobb til en runner, leverer jobbens hemmeligheter når den starter, og runneren strømmer loggene tilbake.

En runnerleverandør erstatter bare den andre halvdelen.

Element	Blir hos GitHub	Flyttes til leverandøren
Repositorium, workflow-filer, triggere	Ja	Nei
Hemmelighetslager	Ja	Hemmeligheter leveres til leverandørens maskin når jobben starter
Jobbtildeling, logger, grensesnitt for sjekker	Ja	Runneren strømmer loggene tilbake
Artefakter fra actions/upload-artifact	Ja	Nei
Utsteder av OIDC-tokener	Ja	Nei, men tokenet sier at runneren er selvhostet
Maskin, image, CPU, minne, disk	Nei	Ja
Utgående nettverksvei og IP-adresser	Nei	Ja
Cachelagring	Avhenger av leverandøren	Avhenger av leverandøren
Minuttfakturering for de flyttede jobbene	Nei	Ja

En tredjepartsrunner registreres hos GitHub som en selvhostet runner. Derfor gjelder GitHubs regler for selvhostede runnere også for den: hvordan etiketter ruter jobber, hvordan runnergrupper begrenser tilgang, hvordan OIDC-tokenet beskriver den og hvordan GitHub fakturerer den.

Endringen i runs-on og etiketter

GitHub ser etter en runner som matcher jobbens runs-on-etiketter og grupper. Hvis ingen matchende runner er tilkoblet, blir jobben stående i kø til en kobler seg til; hvis en tildelt runner ikke plukker opp jobben innen 60 sekunder, settes den i kø på nytt; og en jobb som står i kø i mer enn 24 timer, feiler (GitHubs referanse for selvhostede runnere). En skrivefeil i en etikett, eller en leverandørapp som ikke er installert på repositoriet, viser seg som en jobb som aldri starter.

Leverandørene angir maskinen på én av to måter:

• I etiketten. Ubicloud bruker etiketter som ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 og Avrea avrea-ubuntu-latest-2-vcpu, med arm i etiketten for ARM-maskiner. Å endre størrelse betyr å endre etiketten.
• I et setup-steg. CRACI bruker én etikett, runs-on: craci, og steget cracicorp/setup@v1 velger størrelsen (1 til 32 beregningsenheter på 1 vCPU og 3 GB, standard 2), imaget, nettverkspolicyen eller en runnermal for organisasjonen etter slug. Hvis CRACI ikke kan tolke en inndata, kjører det standardmiljøet og skriver en advarsel i jobbloggen; et ukjent image eller en ukjent mal avvises.

Gjør byttet til én variabel

Legg etiketten i en repositorie- eller organisasjonsvariabel i stedet for å hardkode den. Å bytte frem eller tilbake blir da en endring i innstillingene, ikke en pull request på tvers av alle repositorier.

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

Valget gjøres per jobb, så bygge- og testjobber kan flyttes mens en deploy-jobb blir værende. Variabler kan settes på organisasjonsnivå og overstyres per repositorium, så én innstilling kan flytte en gruppe repositorier og ett repositorium kan velge seg ut.

Gjenbrukbare workflows

Hvis den samme pipelinen er kopiert til mange repositorier, flytt den inn i en gjenbrukbar workflow som leser runneren fra en inndata eller en variabel. Å endre runs-on der endrer alle repositorier som kaller den. Regelsett kan kreve at en workflow kjører i organisasjonens repositorier, noe som holder den delte versjonen i bruk.

Runner-images: kompatibilitet og festing

GitHubs hostede image har et stort forhåndsinstallert verktøysett og en hostet verktøycache. Leverandørene tilbyr enten et image som er kompatibelt med GitHubs, eller et slankere. Jobber er ofte avhengige av ting de aldri deklarerer:

• forhåndsinstallerte språkversjoner og kommandolinjeverktøy;
• sudo uten passord, og systemd for tjenester som startes med systemctl;
• en kjørende Docker-daemon, med Buildx og Compose;
• den hostede verktøycachen som setup-*-actions leser før de laster ned;
• ledig diskplass for store bygg.

Beslutningsregel: Start på leverandørens GitHub-kompatible image. Flytt en jobb til et slankt image først når den er grønn, og legg til eksplisitte setup-*-steg for alt den brukte implisitt.

Festing: ubuntu-latest flytter seg til en ny versjon etter GitHubs tidsplan, og ubuntu-24.04 fester operativsystemversjonen, ikke pakkeversjonene på den. Fest det som betyr noe inne i jobben: setup-actions med eksplisitte versjoner og container-images etter digest. Spør hver leverandør hva den lar deg feste. Selve runner-applikasjonen må fortsette å oppdateres for å kunne snakke med GitHub.

På CRACI er imagene CRACI Slim på x86-64 og ARM64 (Ubuntu 24.04, uten systemd) og et fullt GitHub Actions-kompatibelt Ubuntu 24.04-image, valgt som ubuntu-24.04 eller ubuntu-latest, som følger GitHubs Ubuntu 24.04-runner-image og inkluderer den hostede verktøycachen. Alle imagene har Docker Engine, Buildx og Compose v2.

Cacher: hva som blir med og hva som starter kaldt

De første kjøringene hos en ny leverandør er ofte tregere, og den vanlige årsaken er en kald cache, ikke en treg maskin. Hvordan actions/cache fungerer, avgjør hva du ser (README for actions/cache):

• En oppføring finnes via nøkkelen og en versjon, som er en hash av de cachede stiene og komprimeringsverktøyet.
• Oppføringer er avgrenset per gren; oppføringene fra standardgrenen er tilgjengelige for andre grener.
• Som standard kan et repositorium ha opptil 10 GB cache før de eldste oppføringene fjernes. Repositoriumsadministratorer og eiere av organisasjonen eller enterprise-kontoen kan heve grensen; bruk over 10 GB faktureres kontoen (GitHub om dependency caching).
• En cache lagret på Windows gjenopprettes ikke på et annet operativsystem, eller omvendt, med mindre enableCrossOsArchive er satt; et annet komprimeringsverktøy gir også en annen versjon.

Leverandørene serverer cachen på én av to måter:

Modell	Første kjøringer	Avveining
Runneren bruker GitHubs cachetjeneste, slik GitHub-hostede runnere gjør	Eksisterende oppføringer gjenopprettes	Cachetrafikken går over internett mellom leverandøren og GitHub
Leverandøren serverer cache-API-et fra lagring ved siden av runnerne sine	Vanligvis tom til de første kjøringene fyller den, med mindre leverandøren importerer eller faller tilbake på GitHubs oppføringer	Raskere gjenoppretting; oppføringer skrevet der er vanligvis ikke synlige for GitHub-hostede runnere

Det andre punktet betyr noe for blandede flåter og for tilbakerulling: Hvis du flytter en jobb tilbake, kan den starte kaldt på GitHub også. Spør hvilken modell leverandøren bruker og hvor oppføringene ligger.

Slik skiller du en kald cache fra en treg runner. Ta et Node-bygg som cacher en stor node_modules-mappe. Ved første kjøring hos en ny leverandør rapporterer actions/cache en bom, installasjonssteget laster ned alt, og post-steget lagrer cachen. Fra neste kjøring på samme gren rapporterer steget et treff, og installasjonssteget krymper. Sammenlign kjøringer først når cachen er varm: Les cache-hit-utdataene, og ta tiden på gjenopprettingssteget og installasjonssteget separat fra selve bygget. Se hvordan GitHub Actions-cachen fungerer for nøkler, avgrensning og cacheforgiftning.

På CRACI fungerer actions/cache som i dag, og byggeregistreringen markerer per pakke om den ble gjenopprettet fra en CI-cache i stedet for å bli hentet.

Docker-lagcaching

Mekanisme	Hvor lagene ligger	Hva du bør vite
BuildKit type=gha	GitHub Actions-cachen	Samme avgrensning og størrelsesregler som over; den krever en builder som støtter den
BuildKit type=registry	Et eget image i registeret ditt	Fungerer på alle runnere og overlever et leverandørbytte; du betaler for lagring og overføring i registeret
Leverandørens lokale lagcache eller vedvarende disk	Ved siden av leverandørens runnere	Vanligvis raskest; blir igjen hvis du forlater leverandøren

En registercache er det portable alternativet (Dockers cache-backends):

- 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

To jobber som starter samtidig, gjenoppretter den samme cachen og bygger begge lagene den mangler. Det skjer i all CI, så ikke tolk det som et leverandørproblem.

CRACI tilbyr caching av containerlag med en lokal lagcache, en ekstern lagcache og en bind mount-cache.

Hemmeligheter, OIDC og skylegitimasjon

GitHub lagrer hemmelighetene dine og leverer dem til den runneren som kjører jobben. Å flytte en jobb til en leverandør betyr å betro leverandøren hemmelighetene til den jobben. Spør:

• Får hver jobb sin egen virtuelle maskin, eller en container på en delt vert?
• Slettes maskinen etter jobben, og blir noe beholdt?
• Hvilke logger beholder leverandøren? GitHub maskerer registrerte hemmeligheter i jobblogger og sier at automatisk sladding ikke er garantert for transformerte verdier; spør også om leverandørens egne systemlogger.

OIDC fortsetter å fungere, med én hake. GitHub utsteder OIDC-tokenet, ikke runneren, så permissions: id-token: write fungerer på alle runnere. Men tokenets runner_environment-claim er github-hosted eller self-hosted (GitHubs OIDC-referanse), og på en tredjepartsrunner er det self-hosted. En sky-tillitspolicy som krever github-hosted, avviser jobben. Et eksempel er en workload identity pool i Google Cloud med denne attributtbetingelsen:

# 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'

Å fjerne runnersjekken utvider hvem som kan få legitimasjon, så stram inn en annen betingelse samtidig. Før byttet, søk etter runner_environment i alle sky-tillitspolicyer og konfigurasjoner for workload identity.

Pushe images: GITHUB_TOKEN med packages: write pusher til GitHub Container Registry fra alle runnere, og registerinnlogginger som bruker lagrede hemmeligheter, fungerer uendret.

På CRACI leser GitHub-appen koden din og Actions-kjøringene dine og administrerer runnerne den registrerer for organisasjonen din. Hver jobb kjører i sin egen isolerte virtuelle maskin, og CRACI lagrer ikke kildekoden din.

Nettverksidentitet: IP-tillatelseslister og egress

Den nye runneren går ut fra nye IP-adresser. List opp alt som filtrerer på kildeadresse:

• tillatelseslister for databaser og artefaktrepositorier;
• SaaS-API-er med IP-begrensninger;
• SFTP-servere hos partnere og interne tjenester bak en brannmur.

Alternativene er leverandørens statiske eller stabile utgående IP-adresser, eller en proxy du kontrollerer. Dette er også tidspunktet for å bestemme hva jobbene i det hele tatt får nå: en egress-policy på runneren hindrer en kompromittert avhengighet i å sende hemmeligheter til en vert bygget aldri trengte. Se egress-policy for GitHub Actions.

CRACI tilbyr et stabilt utgående IP-område og en egress-policy, default deny eller allow, som valideres før jobben starter og feiler lukket. Uten en network-inndata tillater standardmalen andre utgående tilkoblinger, så egress-kontroll er noe du konfigurerer.

Blandede flåter: flytt Linux, behold macOS og iOS der de er

Runneren velges per jobb, så én workflow kan kjøre Linux-jobbene sine hos en leverandør og macOS-jobbene på GitHub-hostede runnere. Artefakter lastet opp med actions/upload-artifact lagres av GitHub, så en jobb på én runner kan gi filer videre til en jobb på en annen.

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

Jobbene som blir igjen på GitHub, trekker fortsatt på planens inkluderte bruk og faktureres av GitHub utover den. CRACI kjører Linux på x86-64 og ARM64 i dag, med Windows og macOS på veikartet, så en blandet flåte med CRACI betyr CRACI for Linux og GitHub-hostede runnere for resten.

Fallback når en leverandør er nede

GitHub har ingen innebygd fallback mellom runner-etiketter. Hvis ingen runner for etiketten er tilkoblet, venter jobben, og etter 24 timer feiler den. Planlegg for det:

• Variabelbyttet over: Sett den tilbake til ubuntu-latest, så går nye kjøringer til GitHub-hostede runnere.
• En manuell overstyring for hastekjøringer: en workflow_dispatch-inndata, lest som runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes på jobber, så en jobb som henger, ikke holder igjen en utrulling i timevis.
• Overvåking av køtid, så du merker når jobber venter lenger enn vanlig.

Spør hver leverandør om den tilbyr automatisk fallback og hva som utløser den. Planlegg også for den andre retningen: GitHub setter alle jobber i kø og tildeler dem, så et GitHub Actions-avbrudd stopper også jobber hos alle runnerleverandører.

Fakturering: tar GitHub fortsatt betalt?

GitHub tar ikke betalt per minutt for selvhostede runnere, og tredjepartsrunnere registreres som selvhostede, så minuttene du flytter, forsvinner fra GitHub-fakturaen (fakturering for GitHub Actions). GitHub fakturerer fortsatt:

• seter på planen din;
• lagring av artefakter og cache utover den inkluderte kvoten;
• jobber som blir igjen på GitHub-hostede runnere, utover planens inkluderte bruk, som ikke refunderes.

Under piloten betaler du to fakturaer. Leverandørene teller byggeminutter ulikt: GitHub runder hver jobb opp til hele minuttet, og noen leverandører måler per sekund. For å anslå bruken før og etter, bruk kostnadskalkulatoren for GitHub Actions. CRACI tar bare betalt for byggeminutter: $0.002 per vCPU-minutt ($0.004 for en standard runner med 2 vCPU), målt per sekund, uten månedsavgift.

Sikkerhetsisolasjon: hva du bør spørre enhver leverandør om

Spørsmål	Hvorfor det betyr noe
Én virtuell maskin per jobb, eller containere på en delt vert?	En delt vert lar en kompromittert jobb nå naboene sine
Slettes maskinen etter jobben?	En vedvarende maskin tar med filer, legitimasjon og prosesser inn i neste jobb
Hvor står maskinvaren, og hvem drifter den?	Dataplassering, jurisdiksjon og kundenes kontrakter
Hva lagrer leverandøren, og hvor lenge?	Logger, cacher og nettverksdata kan inneholde sensitivt materiale
Hvilke sertifiseringer har den?	Leverandørvurderingen din kommer til å spørre
Kan du kontrollere egress?	Hindrer at hemmeligheter forsvinner ut gjennom en ondsinnet pakke
Hva kan GitHub-appen lese og endre?	Appens tillatelser gjelder alle repositorier du installerer den på

GitHub sier at selvhostede runnere nesten aldri bør brukes for offentlige repositorier, fordi hvem som helst kan åpne en pull request og kompromittere miljøet, og at just-in-time-runnere kjører maksimalt én jobb før de fjernes (GitHubs referanse for sikker bruk). En ny virtuell maskin per jobb svarer på det meste av den bekymringen.

CRACIs svar: Hver jobb kjører i sin egen isolerte virtuelle maskin på europeisk bare metal-infrastruktur. CRACI Corporation Oys styringssystem for informasjonssikkerhet, for utvikling og drift av CRACI-plattformen, er sertifisert etter ISO/IEC 27001 av Into Certification, med detaljer i Trust Center. CRACI lagrer byggemetadata, pakkedata, nettverksspor, SBOM-er, proveniens, cacher og revisjonsposter, og aldri kildekoden din. Se hva CRACI har tilgang til og sikkerhet.

Prøv ett repositorium først

1. Velg et repositorium med en representativ Linux-workflow som kjører ofte, ikke release-pipelinen.
2. Registrer en baseline på GitHub-hostede runnere: median varighet og køtid over de siste 30 kjøringene, og fakturerte minutter.
3. Installer leverandørens GitHub-app bare på det repositoriet.
4. Bytt én jobb via repositorievariabelen, på en gren.
5. Kjør den minst ti ganger, og se bort fra de tre første som oppvarming av cachen.
6. Sammenlign varighet, køtid, cachetreffrate, feil og kostnad; sjekk logger, OIDC og utgående kall.
7. Rull tilbake ved å endre variabelen, og bekreft at jobben går tilbake til GitHub-hostede runnere.

Måling	Baseline på GitHub-hostede runnere	Leverandør	Terskel for godkjent
Median jobbvarighet			Ditt mål, for eksempel 30 % kortere
Median køtid			Ikke dårligere enn baseline
Cachetreffrate etter oppvarming			Samme som baseline
Mislykkede kjøringer som ikke skyldes koden			Ingen
Kostnad per kjøring			Under baseline
OIDC, tillatelseslister og utgående kall			Alt fungerer

Mål hastigheten på din egen workflow. Alle leverandører publiserer sine egne tall, og det eneste tallet som avgjør ditt tilfelle, er det fra din pipeline.

Slik passer CRACI inn

CRACI er en GitHub Actions-runner. Den erstatter runneren, ikke GitHub Actions: En jobb flyttes med runs-on: craci, størrelser og images settes med cracicorp/setup@v1 eller en runnermal for organisasjonen, og kjøringene vises fortsatt i GitHub. CRACI kjører bygg omtrent dobbelt så raskt som GitHub-hostede runnere, takket være raskere maskinvare, kortere køtider og caching.

Grunnen til å velge den fremfor andre leverandører er hva hver jobb etterlater seg: en SBOM over det bygget hentet, med en fullstendighetsstatus, registrert under en egress-policy som feiler lukket. docs.craci.com tilbyr også en prompt for kodeagenter som foreslår en migreringsplan per jobb for workflowene dine. Se CI/CD-integrasjon.

Når CRACI ikke er svaret

• Du trenger macOS- eller Windows-runnere: De står på CRACIs veikart.
• Du kjører GitHub Enterprise Server, som CRACI ikke støtter.
• CI-en din er GitLab CI eller Jenkins: Begge står på veikartet.
• Runnerne må ligge i din egen skykonto: kundehostede runnere står på veikartet. RunsOn og WarpBuilds bring-your-own-cloud-alternativ gjør det i dag; se CRACI vs RunsOn og CRACI vs WarpBuild.
• Hovedmålet ditt er observerbarhet og feilsøking i CI; se CRACI vs Avrea. For å drifte dine egne runnere, se administrerte vs. selvhostede runnere.

Bytte runnerleverandør: ofte stilte spørsmål

Hva må jeg endre for å bruke en annen runnerleverandør for GitHub Actions?

Installer leverandørens GitHub-app, og endre jobbens runs-on-etikett til leverandørens etikett. Workflows, triggere, hemmeligheter og GitHub-grensesnittet forblir de samme. Før du flytter viktige jobber, sjekk runner-imaget, cachene, utgående IP-adresser, sky-tillitspolicyer som bruker OIDC, fallback og fakturering.

Blir GitHub Actions-cachene mine med over til en ny runnerleverandør?

Det avhenger av hvor leverandøren serverer cachen fra. Hvis runnerne bruker GitHubs cachetjeneste, gjenopprettes eksisterende oppføringer. Hvis leverandøren serverer cache-API-et fra lagring ved siden av runnerne sine, starter cachen vanligvis tom og fylles i de første kjøringene. Spør leverandøren hvilken modell den bruker, og om oppføringer skrevet på runnerne er synlige for GitHub-hostede runnere.

Fungerer Docker-lagcaching på tredjepartsrunnere?

Ja, med hvilken som helst av tre mekanismer: BuildKits type=gha-backend, som bruker Actions-cachen; en registercache med type=registry, som fungerer på alle runnere; eller en lagcache eller vedvarende disk som leverandøren holder ved siden av runnerne sine.

Kan jeg beholde macOS- og iOS-bygg på GitHub mens Linux-jobbene flyttes?

Ja. Runneren velges per jobb, så Linux-jobber kan kjøre hos en leverandør mens macOS-jobber blir på GitHub-hostede runnere i samme workflow. Koble dem med needs: og send filer med actions/upload-artifact og actions/download-artifact, som GitHub lagrer.

Hva skjer med en jobb hvis tredjepartsrunneren er nede? Finnes det en fallback?

GitHub har ingen innebygd fallback mellom runner-etiketter. En jobb med en etikett som ingen tilkoblet runner matcher, blir stående i kø og feiler etter 24 timer. Legg etiketten i en repositorie- eller organisasjonsvariabel, så er det én endring å bytte tilbake, sett timeout-minutes, og spør hver leverandør om den har sin egen fallback.

Fungerer hemmeligheter og OIDC fortsatt på tredjepartsrunnere?

Ja. GitHub lagrer hemmelighetene og leverer dem til runneren når jobben starter, og GitHub utsteder OIDC-tokenet, så id-token: write fungerer på alle runnere. Haken: Tokenets runner_environment-claim er self-hosted på en tredjepartsrunner, så en sky-tillitspolicy som krever github-hosted, avviser jobben.

Fakturerer GitHub meg fortsatt for minutter hvis jeg bruker en annen runnerleverandør?

Ikke for jobbene du flytter. Tredjepartsrunnere registreres hos GitHub som selvhostede runnere, og GitHub oppgir selvhostede runnere som fritatt for minuttavgift. GitHub fakturerer fortsatt seter, lagring utover den inkluderte kvoten og jobber som blir igjen på GitHub-hostede runnere. Leverandøren fakturerer sine egne minutter.

Hvordan fester jeg runner-imaget så det ikke endrer seg uten at jeg vet det?

ubuntu-latest flytter seg etter GitHubs tidsplan, og ubuntu-24.04 fester operativsystemversjonen, men ikke pakkeversjonene på den. Fest det som betyr noe inne i jobben: setup-actions med eksplisitte versjoner og container-images etter digest. Spør hver leverandør hva den lar deg feste; selve runner-applikasjonen må oppdateres for å fortsette å fungere med GitHub.

Hvordan isoleres jobber fra hverandre på en tredjepartsrunner?

Leverandørene er forskjellige. Spør om hver jobb får sin egen virtuelle maskin eller en container på en delt vert, om maskinen slettes etter jobben, og hva leverandøren beholder etterpå. En ny virtuell maskin per jobb er den sterkeste av de vanlige modellene, fordi ingenting fra én jobb blir liggende igjen til den neste.

Hvordan tester jeg en runnerleverandør på ett repositorium først?

Installer leverandørens GitHub-app på ett repositorium, bytt én Linux-jobb som kjører ofte, via en repositorievariabel på en gren, kjør den minst ti ganger, og sammenlign varighet, køtid, cachetreff, feil og kostnad med en baseline på GitHub-hostede runnere. Rull tilbake ved å endre variabelen.