Sådan skifter du runner-udbyder til GitHub Actions: labels, caches, secrets, fakturering og fallback

Denne guide er leverandørneutral. Den forklarer, hvad der flytter, når du skifter runner-udbyder til GitHub Actions, hvad der oftest går i stykker, og hvordan du trækker dig tilbage. Vi bygger CRACI, en af udbyderne; den nævnes, hvor et dokumenteret faktum gælder, og i sit eget afsnit til sidst. Vil du først vælge en udbyder, så se runner-udbydere til GitHub Actions sammenlignet og alternativer til GitHub-hostede runnere.

Hvad ændrer sig, og hvad bliver, når du skifter

GitHub Actions har to halvdele. GitHub er kontrolplanet: Det opbevarer repositoriet og workflow-filerne, udløser triggerne, opbevarer secrets, tildeler jobs, viser logs og checks, gemmer artefakter og udsteder OIDC-tokens. CI-runneren er der, hvor et job udføres: en maskine med et image, CPU, disk, en netværksvej til internettet og som regel en lokal cache. GitHub tildeler et job til en runner, leverer jobbets secrets, når det starter, og runneren streamer logs tilbage.

En runner-udbyder erstatter kun den anden halvdel.

Element	Bliver hos GitHub	Flytter til udbyderen
Repository, workflow-filer, triggere	Ja	Nej
Lager for secrets	Ja	Secrets leveres til udbyderens maskine, når jobbet starter
Tildeling af jobs, logs, brugerflade til checks	Ja	Runneren streamer logs tilbage
Artefakter fra actions/upload-artifact	Ja	Nej
Udsteder af OIDC-tokens	Ja	Nej, men tokenet siger, at runneren er selvhostet
Maskine, image, CPU, hukommelse, disk	Nej	Ja
Udgående netværksvej og IP-adresser	Nej	Ja
Cachelager	Afhænger af udbyderen	Afhænger af udbyderen
Fakturering pr. minut for de flyttede jobs	Nej	Ja

En tredjepartsrunner registrerer sig hos GitHub som en selvhostet runner. Derfor gælder GitHubs regler for selvhostede runnere for den: hvordan labels dirigerer jobs, hvordan runnergrupper begrænser adgang, hvordan OIDC-tokenet beskriver den, og hvordan GitHub fakturerer den.

Ændringen af runs-on og labels

GitHub leder efter en runner, der matcher jobbets runs-on-labels og grupper. Er ingen matchende runner online, bliver jobbet i køen, til der kommer en; hvis en tildelt runner ikke tager jobbet inden for 60 sekunder, sættes det i kø igen; og et job, der står i kø i mere end 24 timer, fejler (GitHubs reference for selvhostede runnere). En tastefejl i en label eller en udbyder-app, der ikke er installeret på repositoriet, viser sig som et job, der aldrig starter.

Udbyderne angiver maskinen på en af to måder:

• I labelen. Ubicloud bruger labels som ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 og Avrea avrea-ubuntu-latest-2-vcpu, med arm i labelen for ARM-maskiner. At skifte størrelse betyder at skifte label.
• I et setup-trin. CRACI bruger én label, runs-on: craci, og trinnet cracicorp/setup@v1 vælger størrelsen (1 til 32 compute-enheder à 1 vCPU og 3 GB, standard 2), imaget, netværkspolitikken eller en runner-skabelon for organisationen ud fra dens slug. Kan CRACI ikke fortolke et input, kører den standardmiljøet og skriver en advarsel i jobloggen; et ukendt image eller en ukendt skabelon afvises.

Gør skiftet til én variabel

Læg labelen i en repository- eller organisationsvariabel i stedet for at hardcode den. Så er det at skifte frem eller tilbage en ændring i indstillingerne, ikke en pull request i hvert eneste repository.

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 sker pr. job, så build- og testjobs kan flytte, mens et deploy-job bliver. Variabler kan sættes på organisationsniveau og overskrives pr. repository, så én indstilling kan flytte en gruppe repositories, og ét repository kan fravælge det.

Genbrugelige workflows

Er den samme pipeline kopieret til mange repositories, så flyt den ind i et genbrugeligt workflow, der læser runneren fra et input eller en variabel. Ændrer du runs-on dér, ændres hvert repository, der kalder det. Rulesets kan kræve, at et workflow kører på en organisations repositories, så den fælles version forbliver i brug.

Runner-images: kompatibilitet og fastlåsning

GitHubs hostede image har et stort forudinstalleret værktøjssæt og en hostet tool cache. Udbyderne tilbyder enten et image, der er kompatibelt med GitHubs, eller et slankere. Jobs afhænger ofte af ting, de aldrig erklærer:

• forudinstallerede sprogversioner og kommandolinjeværktøjer;
• sudo uden adgangskode og systemd til tjenester, der startes med systemctl;
• en kørende Docker-daemon med Buildx og Compose;
• den hostede tool cache, som setup-*-actions læser, før de downloader;
• ledig diskplads til store builds.

Tommelfingerregel: Start på udbyderens GitHub-kompatible image. Flyt først et job til et slankt image, når det er grønt, og tilføj eksplicitte setup-*-trin for alt, det brugte implicit.

Fastlåsning: ubuntu-latest skifter til en ny version efter GitHubs tidsplan, og ubuntu-24.04 fastlåser styresystemets version, ikke pakkeversionerne på det. Fastlås det, der betyder noget, inde i jobbet: setup-actions med eksplicitte versioner og container-images efter digest. Spørg hver udbyder, hvad den lader dig fastlåse. Selve runner-applikationen skal blive ved med at opdatere for at kunne tale med GitHub.

På CRACI er imagene CRACI Slim på x86-64 og ARM64 (Ubuntu 24.04, uden systemd) og et fuldt GitHub Actions-kompatibelt Ubuntu 24.04-image, valgt som ubuntu-24.04 eller ubuntu-latest, der følger GitHubs Ubuntu 24.04-runner-image og indeholder den hostede tool cache. Alle images har Docker Engine, Buildx og Compose v2.

Caches: hvad der følger med, og hvad der starter koldt

De første kørsler hos en ny udbyder er ofte langsommere, og den sædvanlige årsag er en kold cache, ikke en langsom maskine. Hvordan actions/cache virker, afgør, hvad du ser (actions/cache README):

• En post findes ud fra sin nøgle og en version, som er en hash af de cachede stier og komprimeringsværktøjet.
• Poster er afgrænset pr. branch; standard-branchens poster er tilgængelige for andre branches.
• Som standard kan et repository rumme op til 10 GB caches, før de ældste poster fjernes. Repository-administratorer og organisations- eller enterprise-ejere kan hæve grænsen; forbrug ud over 10 GB faktureres til kontoen (GitHub om dependency caching).
• En cache gemt på Windows gendannes ikke på et andet styresystem, eller omvendt, medmindre enableCrossOsArchive er sat; et andet komprimeringsværktøj giver også en anden version.

Udbyderne leverer cachen på en af to måder:

Model	Første kørsler	Afvejning
Runneren bruger GitHubs cachetjeneste, som GitHub-hostede runnere gør	Eksisterende poster gendannes	Cachetrafik krydser internettet mellem udbyderen og GitHub
Udbyderen leverer cache-API'et fra lager ved siden af sine runnere	Som regel tom, til de første kørsler fylder den, medmindre udbyderen importerer eller falder tilbage på GitHubs poster	Hurtigere gendannelse; poster skrevet dér er som regel ikke synlige for GitHub-hostede runnere

Det sidste punkt betyder noget for blandede flåder og for tilbagerulning: Skifter du et job tilbage, kan det også starte koldt på GitHub. Spørg, hvilken model udbyderen bruger, og hvor posterne ligger.

Sådan skelner du en kold cache fra en langsom runner. Tag et Node-build, der cacher en stor node_modules-mappe. Ved den første kørsel hos en ny udbyder rapporterer actions/cache et miss, installationstrinnet downloader alt, og post-trinnet gemmer cachen. Fra næste kørsel på samme branch rapporterer trinnet et hit, og installationstrinnet skrumper. Sammenlign først kørsler, når cachen er varm: Læs cache-hit-outputtet, og tag tid på gendannelsestrinnet og installationstrinnet adskilt fra selve buildet. Se sådan virker GitHub Actions-cachen for nøgler, afgrænsning og cache poisoning.

På CRACI virker actions/cache, som den gør i dag, og build-registreringen markerer pr. pakke, om den blev gendannet fra en CI-cache i stedet for at blive hentet.

Docker-lagcaching

Mekanisme	Hvor lagene ligger	Hvad du skal vide
BuildKit type=gha	GitHub Actions-cachen	Samme afgrænsnings- og størrelsesregler som ovenfor; den kræver en builder, der understøtter den
BuildKit type=registry	Et separat image i dit registry	Virker på enhver runner og overlever et skift af udbyder; du betaler for lager og overførsel i registryet
Lokal lagcache eller vedvarende disk hos udbyderen	Ved siden af udbyderens runnere	Som regel den hurtigste; bliver tilbage, hvis du forlader udbyderen

En registry-cache er den portable løsning (Docker 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 jobs, der starter samtidig, gendanner den samme cache, og begge bygger de lag, den mangler. Det sker på enhver CI, så tolk det ikke som et problem hos udbyderen.

CRACI tilbyder container-lagcaching med en lokal lagcache, en fjern lagcache og en bind mount-cache.

Secrets, OIDC og cloud-legitimationsoplysninger

GitHub opbevarer dine secrets og leverer dem til den runner, der kører jobbet. At flytte et job til en udbyder betyder at betro udbyderen det jobs secrets. Spørg:

• Får hvert job sin egen virtuelle maskine eller en container på en delt host?
• Destrueres maskinen efter jobbet, og gemmes der noget?
• Hvilke logs gemmer udbyderen? GitHub maskerer registrerede secrets i jobloggene og siger, at automatisk redigering ikke er garanteret for transformerede værdier; spørg også til udbyderens egne systemlogs.

OIDC bliver ved med at virke, med én hage. Det er GitHub, ikke runneren, der udsteder OIDC-tokenet, så permissions: id-token: write virker på enhver runner. Men tokenets runner_environment-claim er github-hosted eller self-hosted (GitHubs OIDC-reference), og på en tredjepartsrunner er det self-hosted. En cloud-trust-politik, der kræver github-hosted, afviser jobbet. For eksempel en Google Cloud workload identity pool med denne attributbetingelse:

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

Fjerner du runner-tjekket, udvider du, hvem der kan få legitimationsoplysninger, så stram en anden betingelse samtidig. Gennemsøg før skiftet hver cloud-trust-politik og workload identity-konfiguration for runner_environment.

Push af images: GITHUB_TOKEN med packages: write pusher til GitHub Container Registry fra enhver runner, og registry-logins, der bruger gemte secrets, virker uændret.

På CRACI læser GitHub App'en din kode og dine Actions-kørsler og administrerer de runnere, den registrerer for din organisation. Hvert job kører i sin egen isolerede virtuelle maskine, og CRACI gemmer ikke din kildekode.

Netværksidentitet: IP-allowlists og egress

Den nye runner går ud fra nye IP-adresser. Lav en liste over alt, der filtrerer på kildeadresse:

• allowlists til databaser og artefakt-repositories;
• SaaS-API'er med IP-begrænsninger;
• partneres SFTP-servere og interne tjenester bag en firewall.

Mulighederne er udbyderens statiske eller stabile udgående IP-adresser eller en proxy, du selv kontrollerer. Det er også tidspunktet til at beslutte, hvad jobs overhovedet må nå: En egress-politik på runneren forhindrer en kompromitteret afhængighed i at sende secrets til en host, buildet aldrig havde brug for. Se egress-politik for GitHub Actions.

CRACI tilbyder et stabilt udgående IP-område og en egress-politik, default deny eller allow, der valideres, før jobbet starter, og blokerer ved fejl. Uden et network-input tillader standardskabelonen andre udgående forbindelser, så egress-kontrol er noget, du konfigurerer.

Blandede flåder: flyt Linux, behold macOS og iOS, hvor de er

Runneren vælges pr. job, så ét workflow kan køre sine Linux-jobs hos en udbyder og sine macOS-jobs på GitHub-hostede runnere. Artefakter uploadet med actions/upload-artifact opbevares af GitHub, så et job på én runner kan give filer videre til et job på en anden.

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

De jobs, der bliver på GitHub, trækker stadig på din plans inkluderede forbrug og faktureres af GitHub ud over det. CRACI kører Linux på x86-64 og ARM64 i dag, med Windows og macOS på roadmappen, så en blandet flåde med CRACI betyder CRACI til Linux og GitHub-hostede runnere til resten.

Fallback, når en udbyder er nede

GitHub har ingen indbygget fallback mellem runner-labels. Er ingen runner til labelen online, venter jobbet, og efter 24 timer fejler det. Planlæg for det:

• Variabelskiftet ovenfor: Sæt det tilbage til ubuntu-latest, og nye kørsler går til GitHub-hostede runnere.
• En manuel tilsidesættelse til hastende kørsler: et workflow_dispatch-input, læst som runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes på jobs, så et job, der hænger, ikke holder en udrulning tilbage i timevis.
• Overvågning af ventetid i kø, så du opdager, når jobs venter længere end normalt.

Spørg hver udbyder, om den tilbyder en automatisk fallback, og hvad der udløser den. Planlæg også for den modsatte retning: GitHub sætter hvert job i kø og tildeler det, så et nedbrud i GitHub Actions også stopper jobs hos alle runner-udbydere.

Fakturering: tager GitHub stadig betaling?

GitHub tager ikke betaling pr. minut for selvhostede runnere, og tredjepartsrunnere registrerer sig som selvhostede, så de minutter, du flytter, forsvinder fra GitHub-regningen (fakturering af GitHub Actions). GitHub fakturerer stadig:

• licenser på din plan;
• artefakt- og cachelager, det opbevarer ud over det inkluderede;
• jobs, der bliver på GitHub-hostede runnere, ud over din plans inkluderede forbrug, som ikke refunderes.

Under piloten betaler du to fakturaer. Udbyderne tæller build-minutter forskelligt: GitHub runder hvert job op til et helt minut, og nogle udbydere måler pr. sekund. Brug prisberegneren til GitHub Actions til at beregne dit forbrug før og efter. CRACI tager kun betaling for build-minutter: $0.002 pr. vCPU-minut ($0.004 for en standardrunner med 2 vCPU), målt pr. sekund, uden månedligt gebyr.

Sikkerhedsisolering: hvad du skal spørge enhver udbyder om

Spørgsmål	Hvorfor det betyder noget
Én virtuel maskine pr. job eller containere på en delt host?	En delt host lader et kompromitteret job nå sine naboer
Destrueres maskinen efter jobbet?	En vedvarende maskine bærer filer, legitimationsoplysninger og processer videre til næste job
Hvor står hardwaren, og hvem driver den?	Dataplacering, jurisdiktion og dine kunders kontrakter
Hvad gemmer udbyderen, og hvor længe?	Logs, caches og netværksdata kan indeholde følsomt materiale
Hvilke certificeringer har den?	Din leverandørvurdering vil spørge
Kan du kontrollere egress?	Forhindrer secrets i at slippe ud gennem en ondsindet pakke
Hvad kan dens GitHub App læse og ændre?	App'ens rettigheder gælder for hvert repository, du installerer den på

GitHub siger, at selvhostede runnere næsten aldrig bør bruges til offentlige repositories, fordi enhver kan åbne en pull request og kompromittere miljøet, og at just-in-time-runnere højst kører ét job, før de fjernes (GitHubs reference for sikker brug). En frisk virtuel maskine pr. job imødekommer det meste af den bekymring.

CRACIs svar: Hvert job kører i sin egen isolerede virtuelle maskine på europæisk bare metal-infrastruktur. CRACI Corporation Oy's ledelsessystem for informationssikkerhed, for udvikling og drift af CRACI-platformen, er certificeret efter ISO/IEC 27001 af Into Certification, med detaljer i Trust Center. CRACI gemmer build-metadata, pakkedata, netværkstraces, SBOM'er, provenance, caches og audit-poster og aldrig din kildekode. Se hvad CRACI kan nå og sikkerhed.

Prøv ét repository først

1. Vælg et repository med et repræsentativt, ofte kørt Linux-workflow, ikke release-pipelinen.
2. Registrér en baseline på GitHub-hostede runnere: median varighed og ventetid i kø over de seneste 30 kørsler samt fakturerede minutter.
3. Installér udbyderens GitHub App kun på det repository.
4. Skift ét job via repository-variablen på en branch.
5. Kør det mindst ti gange, og se bort fra de første tre som opvarmning af cachen.
6. Sammenlign varighed, ventetid i kø, cache-hitrate, fejl og pris; tjek logs, OIDC og udgående kald.
7. Rul tilbage ved at ændre variablen, og bekræft, at jobbet vender tilbage til GitHub-hostede runnere.

Måling	GitHub-hostet baseline	Udbyder	Bestået ved
Median varighed pr. job			Dit mål, for eksempel 30 % kortere
Median ventetid i kø			Ikke værre end baselinen
Cache-hitrate efter opvarmning			Samme som baselinen
Fejlede kørsler, der ikke skyldes koden			Ingen
Pris pr. kørsel			Under baselinen
OIDC, allowlists og udgående kald			Alle virker

Mål hastigheden på dit eget workflow. Hver udbyder offentliggør sine egne tal, og det eneste tal, der afgør din sag, er det fra din pipeline.

Hvor CRACI passer ind

CRACI er en GitHub Actions-runner. Den erstatter runneren, ikke GitHub Actions: Et job flytter med runs-on: craci, størrelser og images sættes med cracicorp/setup@v1 eller en runner-skabelon for organisationen, og kørsler vises stadig i GitHub. CRACI kører builds cirka dobbelt så hurtigt som GitHub-hostede runnere takket være hurtigere hardware, kortere ventetid i kø og caching.

Grunden til at vælge den frem for andre udbydere er, hvad hvert job efterlader: en SBOM over det, buildet hentede, med en fuldstændighedsstatus, registreret under en egress-politik, der blokerer ved fejl. docs.craci.com tilbyder også en prompt til kodeagenter, der foreslår en migreringsplan pr. job for dine workflows. Se CI/CD-integration.

Når CRACI ikke er svaret

• Du har brug for macOS- eller Windows-runnere: De er på CRACIs roadmap.
• Du kører GitHub Enterprise Server, som CRACI ikke understøtter.
• Din CI er GitLab CI eller Jenkins: Begge er på roadmappen.
• Runnere skal ligge i din egen cloud-konto: kundehostede runnere er på roadmappen. RunsOn og WarpBuilds bring-your-own-cloud-mulighed gør det i dag; se CRACI vs RunsOn og CRACI vs WarpBuild.
• Dit hovedmål er CI-observability og fejlfinding; se CRACI vs Avrea. Vil du køre dine egne runnere, så se administrerede vs. selvhostede runnere.

Skift af runner-udbyder: ofte stillede spørgsmål

Hvad skal jeg ændre for at bruge en anden runner-udbyder til GitHub Actions?

Installér udbyderens GitHub App, og skift jobbets runs-on-label til udbyderens label. Workflows, triggere, secrets og GitHubs brugerflade forbliver de samme. Før du flytter vigtige jobs, så tjek runner-imaget, caches, udgående IP-adresser, cloud-trust-politikker, der bruger OIDC, fallback og fakturering.

Følger mine GitHub Actions-caches med til en ny runner-udbyder?

Det afhænger af, hvor udbyderen leverer cachen fra. Bruger dens runnere GitHubs cachetjeneste, gendannes eksisterende poster. Leverer den cache-API'et fra lager ved siden af sine runnere, starter cachen som regel tom og fyldes ved de første kørsler. Spørg udbyderen, hvilken model den bruger, og om poster skrevet på dens runnere er synlige for GitHub-hostede runnere.

Virker Docker-lagcaching på tredjepartsrunnere?

Ja, med en af tre mekanismer: BuildKits type=gha-backend, der bruger Actions-cachen; en registry-cache med type=registry, der virker på enhver runner; eller en lagcache eller vedvarende disk, som udbyderen holder ved siden af sine runnere.

Kan jeg beholde macOS- og iOS-builds på GitHub, mens Linux-jobs flytter?

Ja. Runneren vælges pr. job, så Linux-jobs kan køre hos en udbyder, mens macOS-jobs bliver på GitHub-hostede runnere i det samme workflow. Forbind dem med needs:, og overfør filer med actions/upload-artifact og actions/download-artifact, som GitHub opbevarer.

Hvad sker der med et job, hvis tredjepartsrunneren er nede? Er der en fallback?

GitHub har ingen indbygget fallback mellem runner-labels. Et job, hvis label ingen online runner matcher, bliver i køen og fejler efter 24 timer. Gem labelen i en repository- eller organisationsvariabel, så det at skifte tilbage er én ændring, sæt timeout-minutes, og spørg hver udbyder, om den tilbyder sin egen fallback.

Virker secrets og OIDC stadig på tredjepartsrunnere?

Ja. GitHub opbevarer secrets og leverer dem til runneren, når jobbet starter, og GitHub udsteder OIDC-tokenet, så id-token: write virker på enhver runner. Haken: Tokenets runner_environment-claim er self-hosted på en tredjepartsrunner, så en cloud-trust-politik, der kræver github-hosted, afviser jobbet.

Tager GitHub stadig betaling for minutter, hvis jeg bruger en anden runner-udbyder?

Ikke for de jobs, du flytter. Tredjepartsrunnere registrerer sig hos GitHub som selvhostede runnere, og GitHub angiver selvhostede runnere som fri for betaling pr. minut. GitHub fakturerer stadig licenser, lager ud over det inkluderede og jobs, der bliver på GitHub-hostede runnere. Udbyderen fakturerer sine egne minutter.

Hvordan fastlåser jeg runner-imaget, så det ikke ændrer sig under mig?

ubuntu-latest skifter efter GitHubs tidsplan, og ubuntu-24.04 fastlåser styresystemets version, men ikke pakkeversionerne på det. Fastlås det, der betyder noget, inde i jobbet: setup-actions med eksplicitte versioner og container-images efter digest. Spørg hver udbyder, hvad den lader dig fastlåse; selve runner-applikationen skal opdateres for at blive ved med at virke med GitHub.

Hvordan isoleres jobs fra hinanden på en tredjepartsrunner?

Udbyderne er forskellige. Spørg, om hvert job får sin egen virtuelle maskine eller en container på en delt host, om maskinen destrueres efter jobbet, og hvad udbyderen gemmer bagefter. En frisk virtuel maskine pr. job er den stærkeste af de almindelige modeller, fordi intet fra ét job efterlades til det næste.

Hvordan tester jeg en runner-udbyder på ét repository først?

Installér udbyderens GitHub App på ét repository, skift ét ofte kørt Linux-job via en repository-variabel på en branch, kør det mindst ti gange, og sammenlign varighed, ventetid i kø, cache-hits, fejl og pris med en GitHub-hostet baseline. Rul tilbage ved at ændre variablen.