Jak změnit poskytovatele runnerů GitHub Actions: labely, cache, secrets, účtování a fallback

Tento průvodce je nezávislý na dodavateli. Vysvětluje, co se přesouvá, když měníte poskytovatele runnerů GitHub Actions, co se nejčastěji rozbije a jak se vrátit. CRACI, jednoho z poskytovatelů, vyvíjíme my; objevuje se tam, kde platí zdokumentovaný fakt, a ve vlastní části na konci. Pokud si nejdřív chcete vybrat poskytovatele, podívejte se na srovnání poskytovatelů runnerů GitHub Actions a alternativy k runnerům hostovaným na GitHubu.

Co se při změně mění a co zůstává

GitHub Actions má dvě poloviny. GitHub je řídicí vrstva: ukládá repozitář a soubory workflow, spouští triggery, ukládá secrets, přiděluje joby, zobrazuje logy a checky, uchovává artefakty a vydává tokeny OIDC. CI runner je místo, kde job běží: stroj s image, CPU, diskem, síťovou cestou do internetu a obvykle lokální cache. GitHub přidělí job runneru, při jeho startu doručí secrets jobu a runner posílá logy zpět.

Poskytovatel runnerů nahrazuje pouze druhou polovinu.

Položka	Zůstává u GitHubu	Přechází k poskytovateli
Repozitář, soubory workflow, triggery	Ano	Ne
Úložiště secrets	Ano	Secrets se doručují na stroj poskytovatele při startu jobu
Přidělování jobů, logy, rozhraní checků	Ano	Runner posílá logy zpět
Artefakty z actions/upload-artifact	Ano	Ne
Vydavatel tokenů OIDC	Ano	Ne, ale token uvádí, že runner je self-hosted
Stroj, image, CPU, paměť, disk	Ne	Ano
Odchozí síťová cesta a IP adresy	Ne	Ano
Úložiště cache	Záleží na poskytovateli	Záleží na poskytovateli
Účtování za minutu u přesunutých jobů	Ne	Ano

Runner třetí strany se u GitHubu registruje jako self-hosted runner. Proto se na něj vztahují pravidla GitHubu pro self-hosted runnery: jak labely směrují joby, jak skupiny runnerů omezují přístup, jak ho popisuje token OIDC a jak ho GitHub účtuje.

Změna runs-on a labely

GitHub hledá runner, který odpovídá labelům a skupinám runs-on daného jobu. Pokud žádný odpovídající runner není online, job zůstane ve frontě, dokud se nějaký neobjeví; pokud přidělený runner job nepřevezme do 60 sekund, vrátí se do fronty; a job, který zůstane ve frontě déle než 24 hodin, selže (reference GitHubu k self-hosted runnerům). Překlep v labelu nebo aplikace poskytovatele, která není na repozitáři nainstalovaná, se projeví jako job, který se nikdy nespustí.

Poskytovatelé zadávají stroj jedním ze dvou způsobů:

• V labelu. Ubicloud používá labely jako ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 a Avrea avrea-ubuntu-latest-2-vcpu, s arm v labelu pro stroje ARM. Změna velikosti znamená změnu labelu.
• V kroku setup. CRACI používá jeden label, runs-on: craci, a krok cracicorp/setup@v1 volí velikost (1 až 32 výpočetních jednotek po 1 vCPU a 3 GB, výchozí 2), image, síťovou politiku nebo šablonu runneru organizace podle jejího slugu. Pokud CRACI nedokáže vstup zpracovat, spustí výchozí prostředí a zapíše varování do logu jobu; neznámý image nebo šablona se odmítne.

Udělejte z přepnutí jednu proměnnou

Uložte label do proměnné repozitáře nebo organizace, místo abyste ho napevno zapsali. Přepnutí tam i zpět je pak změna nastavení, ne pull request napříč všemi repozitáři.

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

Volí se pro každý job zvlášť, takže joby buildu a testů mohou přejít, zatímco job nasazení zůstane. Proměnné lze nastavit na úrovni organizace a přepsat pro jednotlivé repozitáře, takže jedno nastavení může přesunout skupinu repozitářů a jeden repozitář se může vyřadit.

Opakovaně použitelná workflow

Pokud je stejná pipeline zkopírovaná v mnoha repozitářích, přesuňte ji do opakovaně použitelného workflow, které čte runner ze vstupu nebo z proměnné. Změna runs-on tam změní každý repozitář, který ho volá. Rulesety mohou vyžadovat spuštění workflow v repozitářích organizace, což udržuje sdílenou verzi v používání.

Image runnerů: kompatibilita a připínání

Hostovaný image GitHubu obsahuje rozsáhlou předinstalovanou sadu nástrojů a hostovanou tool cache. Poskytovatelé nabízejí buď image kompatibilní s GitHubem, nebo štíhlejší. Joby často závisejí na věcech, které nikdy nedeklarují:

• předinstalované verze jazyků a nástroje příkazové řádky;
• sudo bez hesla a systemd pro služby spouštěné přes systemctl;
• běžící démon Dockeru s Buildx a Compose;
• hostovanou tool cache, kterou actions setup-* čtou, než začnou stahovat;
• volné místo na disku pro velké buildy.

Rozhodovací pravidlo: začněte na image poskytovatele kompatibilním s GitHubem. Na štíhlý image přesuňte job až poté, co je zelený, a přidejte explicitní kroky setup-* pro všechno, co používal implicitně.

Připínání: ubuntu-latest přechází na nové vydání podle harmonogramu GitHubu a ubuntu-24.04 připíná vydání operačního systému, ne verze balíčků v něm. Připněte to, na čem záleží, uvnitř jobu: setup actions s explicitními verzemi a image kontejnerů podle digestu. Zeptejte se každého poskytovatele, co vám dovolí připnout. Samotná aplikace runneru se musí dál aktualizovat, aby mohla komunikovat s GitHubem.

Na CRACI jsou k dispozici image CRACI Slim na x86-64 a ARM64 (Ubuntu 24.04, bez systemd) a plný image Ubuntu 24.04 kompatibilní s GitHub Actions, volený jako ubuntu-24.04 nebo ubuntu-latest, který sleduje image runneru Ubuntu 24.04 od GitHubu a obsahuje hostovanou tool cache. Každý image má Docker Engine, Buildx a Compose v2.

Cache: co se přenese a co začíná nanovo

První běhy u nového poskytovatele bývají pomalejší a obvyklým důvodem je studená cache, ne pomalý stroj. To, co uvidíte, určuje způsob, jakým funguje actions/cache (README actions/cache):

• Záznam se hledá podle klíče a verze, což je hash cachovaných cest a kompresního nástroje.
• Záznamy jsou vázané na větev; záznamy výchozí větve jsou dostupné i ostatním větvím.
• Ve výchozím nastavení může repozitář držet až 10 GB cache, než se nejstarší záznamy vyřadí. Administrátoři repozitáře a vlastníci organizace nebo enterprise mohou limit zvýšit; využití nad 10 GB se účtuje na účet (GitHub dependency caching).
• Cache uložená na Windows se neobnoví na jiném operačním systému ani naopak, pokud není nastaveno enableCrossOsArchive; jiný kompresní nástroj také dává jinou verzi.

Poskytovatelé obsluhují cache jedním ze dvou způsobů:

Model	První běhy	Kompromis
Runner používá cache službu GitHubu stejně jako runnery hostované na GitHubu	Existující záznamy se obnoví	Provoz cache prochází internetem mezi poskytovatelem a GitHubem
Poskytovatel obsluhuje cache API z úložiště vedle svých runnerů	Obvykle prázdná, dokud ji první běhy nenaplní, pokud poskytovatel neimportuje záznamy GitHubu nebo na ně nepřepadá	Rychlejší obnovení; záznamy zapsané tam obvykle nejsou viditelné pro runnery hostované na GitHubu

Druhý bod je důležitý pro smíšené flotily a pro návrat: pokud job přepnete zpět, může i na GitHubu začít se studenou cache. Zeptejte se, který model poskytovatel používá a kde záznamy leží.

Jak rozlišit studenou cache od pomalého runneru. Vezměte build v Node, který cachuje velký adresář node_modules. Při prvním běhu u nového poskytovatele hlásí actions/cache miss, krok instalace stáhne všechno a post krok cache uloží. Od dalšího běhu ve stejné větvi hlásí krok hit a krok instalace se zkrátí. Porovnávejte běhy až po zahřátí cache: čtěte výstup cache-hit a měřte krok obnovení a krok instalace odděleně od samotného buildu. Klíče, rozsahy a cache poisoning popisuje článek jak funguje cache GitHub Actions.

Na CRACI funguje actions/cache stejně jako dnes a záznam buildu u každého balíčku označí, zda byl obnoven z cache CI, místo aby byl stažen.

Cachování vrstev Dockeru

Mechanismus	Kde vrstvy leží	Co je dobré vědět
BuildKit type=gha	V cache GitHub Actions	Stejná pravidla rozsahu a velikosti jako výše; vyžaduje builder, který ho podporuje
BuildKit type=registry	Samostatný image ve vašem registru	Funguje na jakémkoli runneru a přežije změnu poskytovatele; platíte za úložiště a přenosy registru
Lokální cache vrstev nebo trvalý disk poskytovatele	Vedle runnerů poskytovatele	Obvykle nejrychlejší; zůstane u poskytovatele, pokud odejdete

Přenositelnou možností je cache v registru (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

Dva joby, které začnou ve stejnou chvíli, obnoví stejnou cache a oba sestaví vrstvy, které v ní chybí. To se děje v jakémkoli CI, takže to nepovažujte za problém poskytovatele.

CRACI nabízí cachování vrstev kontejnerů s lokální cache vrstev, vzdálenou cache vrstev a bind mount cache.

Secrets, OIDC a cloudové přihlašovací údaje

GitHub ukládá vaše secrets a doručuje je tomu runneru, který job spouští. Přesunout job k poskytovateli znamená svěřit tomuto poskytovateli secrets daného jobu. Zeptejte se:

• Dostane každý job vlastní virtuální stroj, nebo kontejner na sdíleném hostiteli?
• Zničí se stroj po jobu a uchovává se něco?
• Které logy poskytovatel uchovává? GitHub maskuje registrované secrets v logech jobů a uvádí, že automatické začernění není zaručeno u transformovaných hodnot; zeptejte se i na vlastní systémové logy poskytovatele.

OIDC funguje dál, s jedním háčkem. Token OIDC vydává GitHub, ne runner, takže permissions: id-token: write funguje na jakémkoli runneru. Claim runner_environment v tokenu má ale hodnotu github-hosted nebo self-hosted (reference GitHubu k OIDC), a na runneru třetí strany je to self-hosted. Cloudová politika důvěry, která vyžaduje github-hosted, job odmítne. Například workload identity pool v Google Cloud s touto podmínkou atributu:

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

Odstranění kontroly runneru rozšiřuje okruh toho, kdo může získat přihlašovací údaje, proto současně zpřísněte jinou podmínku. Před přepnutím prohledejte všechny cloudové politiky důvěry a konfigurace workload identity na runner_environment.

Push image: GITHUB_TOKEN s packages: write pushuje do GitHub Container Registry z jakéhokoli runneru a přihlášení k registrům, která používají uložené secrets, fungují beze změny.

Na CRACI čte GitHub App váš kód a vaše běhy Actions a spravuje runnery, které pro vaši organizaci registruje. Každý job běží ve vlastním izolovaném virtuálním stroji a CRACI neukládá váš zdrojový kód.

Síťová identita: IP allowlisty a odchozí provoz

Nový runner odchází z nových IP adres. Sepište vše, co filtruje podle zdrojové adresy:

• allowlisty databází a repozitářů artefaktů;
• SaaS API s omezením IP;
• SFTP servery partnerů a interní služby za firewallem.

Možnostmi jsou statické nebo stabilní odchozí IP adresy poskytovatele, nebo proxy, kterou máte pod kontrolou. Je to také chvíle rozhodnout, kam se joby vůbec smí připojit: egress policy na runneru zabrání kompromitované závislosti odeslat secrets na hostitele, kterého build nikdy nepotřeboval. Viz egress policy pro GitHub Actions.

CRACI nabízí stabilní rozsah odchozích IP adres a egress policy s výchozím zákazem nebo povolením, která se ověří před spuštěním jobu a při selhání vše zablokuje (fail-closed). Bez vstupu network povoluje výchozí šablona i ostatní odchozí spojení, takže kontrolu odchozího provozu si nastavujete sami.

Smíšené flotily: Linux přesuňte, macOS a iOS nechte, kde jsou

Runner se volí pro každý job zvlášť, takže jedno workflow může spouštět své linuxové joby u poskytovatele a joby pro macOS na runnerech hostovaných na GitHubu. Artefakty nahrané přes actions/upload-artifact ukládá GitHub, takže job na jednom runneru může předat soubory jobu na jiném.

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

Joby ponechané na GitHubu dál čerpají z využití zahrnutého ve vašem plánu a nad jeho rámec je účtuje GitHub. CRACI dnes běží na Linuxu x86-64 a ARM64, Windows a macOS jsou v plánu vývoje, takže smíšená flotila s CRACI znamená CRACI pro Linux a runnery hostované na GitHubu pro zbytek.

Fallback, když poskytovatel nefunguje

GitHub nemá žádný vestavěný fallback mezi labely runnerů. Pokud pro label není online žádný runner, job čeká a po 24 hodinách selže. Připravte se na to:

• Přepínač přes proměnnou výše: nastavte ji zpět na ubuntu-latest a nové běhy půjdou na runnery hostované na GitHubu.
• Ruční přepsání pro naléhavé běhy: vstup workflow_dispatch, čtený jako runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes u jobů, aby job, který se zasekne, nedržel nasazení celé hodiny.
• Monitorování doby ve frontě, abyste si všimli, když joby čekají déle než obvykle.

Zeptejte se každého poskytovatele, zda nabízí automatický fallback a co ho spouští. Počítejte i s opačným směrem: GitHub řadí do fronty a přiděluje každý job, takže výpadek GitHub Actions zastaví joby i u všech poskytovatelů runnerů.

Účtování: platí se GitHubu dál?

GitHub neúčtuje self-hosted runnery po minutách a runnery třetích stran se registrují jako self-hosted, takže minuty, které přesunete, z účtu od GitHubu zmizí (účtování GitHub Actions). GitHub dál účtuje:

• licence ve vašem plánu;
• úložiště artefaktů a cache, které drží nad rámec zahrnutého limitu;
• joby ponechané na runnerech hostovaných na GitHubu nad rámec využití zahrnutého ve vašem plánu, které se nevrací.

Během pilotu platíte dvě faktury. Poskytovatelé počítají minuty buildu různě: GitHub zaokrouhluje každý job nahoru na celou minutu a někteří poskytovatelé účtují po sekundách. K odhadu spotřeby před přechodem a po něm použijte kalkulačku nákladů GitHub Actions. CRACI účtuje jen minuty buildu: $0.002 za vCPU-minutu ($0.004 za výchozí runner s 2 vCPU), účtováno po sekundách, bez měsíčního poplatku.

Bezpečnostní izolace: na co se zeptat kteréhokoli poskytovatele

Otázka	Proč na tom záleží
Jeden virtuální stroj na job, nebo kontejnery na sdíleném hostiteli?	Sdílený hostitel umožní kompromitovanému jobu dostat se k sousedům
Zničí se stroj po jobu?	Trvalý stroj přenáší soubory, přihlašovací údaje a procesy do dalšího jobu
Kde je hardware a kdo ho provozuje?	Umístění dat, jurisdikce a smlouvy vašich zákazníků
Co poskytovatel ukládá a jak dlouho?	Logy, cache a síťová data mohou obsahovat citlivé informace
Jaké certifikace má?	Vaše prověrka dodavatelů se na to zeptá
Můžete řídit odchozí provoz?	Zabrání úniku secrets přes škodlivý balíček
Co může jeho GitHub App číst a měnit?	Oprávnění aplikace platí pro každý repozitář, na který ji nainstalujete

GitHub uvádí, že self-hosted runnery by se pro veřejné repozitáře neměly používat téměř nikdy, protože kdokoli může otevřít pull request a kompromitovat prostředí, a že just-in-time runnery spustí nejvýše jeden job, než jsou odstraněny (reference GitHubu k bezpečnému používání). Nový virtuální stroj pro každý job řeší většinu těchto obav.

Odpovědi CRACI: každý job běží ve vlastním izolovaném virtuálním stroji na evropské bare-metal infrastruktuře. Systém řízení bezpečnosti informací společnosti CRACI Corporation Oy pro vývoj a provoz platformy CRACI je certifikován podle ISO/IEC 27001 společností Into Certification, podrobnosti najdete v Trust Center. CRACI ukládá metadata buildů, data o balíčcích, síťové záznamy, SBOM, provenance, cache a auditní záznamy, nikdy však váš zdrojový kód. Viz k čemu má CRACI přístup a zabezpečení.

Nejdřív vyzkoušejte jeden repozitář

1. Vyberte repozitář s reprezentativním, často spouštěným linuxovým workflow, ne release pipeline.
2. Zaznamenejte výchozí stav na runnerech hostovaných na GitHubu: medián doby trvání a doby ve frontě za posledních 30 běhů a účtované minuty.
3. Nainstalujte GitHub App poskytovatele pouze na tento repozitář.
4. Přepněte jeden job přes proměnnou repozitáře ve větvi.
5. Spusťte ho alespoň desetkrát a první tři běhy vyřaďte jako zahřívání cache.
6. Porovnejte dobu trvání, dobu ve frontě, úspěšnost cache, selhání a náklady; zkontrolujte logy, OIDC a odchozí volání.
7. Vraťte se změnou proměnné a ověřte, že se job vrátí na runnery hostované na GitHubu.

Metrika	Výchozí stav GitHub-hosted	Poskytovatel	Práh úspěchu
Medián doby trvání jobu			Váš cíl, například o 30 % kratší
Medián doby ve frontě			Ne horší než výchozí stav
Úspěšnost cache po zahřátí			Stejná jako výchozí stav
Neúspěšné běhy nezpůsobené kódem			Žádné
Náklady na běh			Pod výchozím stavem
OIDC, allowlisty a odchozí volání			Vše funguje

Rychlost měřte na vlastním workflow. Každý poskytovatel zveřejňuje vlastní čísla a jediné číslo, které rozhoduje ve vašem případě, je to z vaší pipeline.

Kde se uplatní CRACI

CRACI je runner pro GitHub Actions. Nahrazuje runner, ne GitHub Actions: job se přesune pomocí runs-on: craci, velikosti a image se nastavují přes cracicorp/setup@v1 nebo šablonu runneru organizace a běhy se dál zobrazují v GitHubu. CRACI spouští buildy přibližně dvakrát rychleji než runnery hostované na GitHubu díky rychlejšímu hardwaru, kratším frontám a cache.

Důvodem zvolit ho místo jiných poskytovatelů je to, co po sobě každý job zanechá: SBOM toho, co build stáhl, se stavem úplnosti, zaznamenanou pod egress policy, která při selhání vše zablokuje. Na docs.craci.com je také prompt pro kódovací agenty, který pro vaše workflow navrhne plán migrace po jednotlivých jobech. Viz integrace CI/CD.

Kdy CRACI není řešením

• Potřebujete runnery pro macOS nebo Windows: jsou v plánu vývoje CRACI.
• Provozujete GitHub Enterprise Server, který CRACI nepodporuje.
• Vaše CI je GitLab CI nebo Jenkins: obojí je v plánu vývoje.
• Runnery musí běžet ve vašem vlastním cloudovém účtu: runnery hostované zákazníkem jsou v plánu vývoje. RunsOn a možnost bring-your-own-cloud od WarpBuild to umějí už dnes; viz CRACI vs RunsOn a CRACI vs WarpBuild.
• Vaším hlavním cílem je observabilita a ladění CI; viz CRACI vs Avrea. Pro provoz vlastních runnerů viz spravované vs self-hosted runnery.

Změna poskytovatele runnerů: časté dotazy

Co musím změnit, abych mohl používat jiného poskytovatele runnerů GitHub Actions?

Nainstalujte GitHub App poskytovatele a pak změňte label runs-on u jobu na label poskytovatele. Workflow, triggery, secrets i rozhraní GitHubu zůstávají stejné. Než přesunete důležité joby, zkontrolujte image runneru, cache, odchozí IP adresy, cloudové politiky důvěry, které používají OIDC, fallback a účtování.

Přenesou se moje cache GitHub Actions k novému poskytovateli runnerů?

Záleží na tom, odkud poskytovatel cache obsluhuje. Pokud jeho runnery používají cache službu GitHubu, existující záznamy se obnoví. Pokud obsluhuje cache API z úložiště vedle svých runnerů, cache obvykle začíná prázdná a naplní se při prvních bězích. Zeptejte se poskytovatele, který model používá a zda jsou záznamy zapsané na jeho runnerech viditelné pro runnery hostované na GitHubu.

Funguje cachování vrstev Dockeru na runnerech třetích stran?

Ano, s kterýmkoli ze tří mechanismů: backend BuildKitu type=gha, který používá cache Actions; cache v registru s type=registry, která funguje na jakémkoli runneru; nebo cache vrstev či trvalý disk, který poskytovatel udržuje vedle svých runnerů.

Mohu si nechat buildy pro macOS a iOS na GitHubu, zatímco linuxové joby přejdou jinam?

Ano. Runner se volí pro každý job zvlášť, takže linuxové joby mohou běžet u poskytovatele, zatímco joby pro macOS zůstanou ve stejném workflow na runnerech hostovaných na GitHubu. Propojte je pomocí needs: a soubory předávejte přes actions/upload-artifact a actions/download-artifact, které ukládá GitHub.

Co se stane s jobem, když runner třetí strany nefunguje? Existuje fallback?

GitHub nemá žádný vestavěný fallback mezi labely runnerů. Job, jehož labelu neodpovídá žádný runner online, zůstane ve frontě a po 24 hodinách selže. Uložte label do proměnné repozitáře nebo organizace, aby návrat zpět byla jedna změna, nastavte timeout-minutes a zeptejte se každého poskytovatele, zda nabízí vlastní fallback.

Fungují secrets a OIDC i na runnerech třetích stran?

Ano. GitHub ukládá secrets a doručuje je runneru při startu jobu a token OIDC vydává GitHub, takže id-token: write funguje na jakémkoli runneru. Háček: claim runner_environment v tokenu má na runneru třetí strany hodnotu self-hosted, takže cloudová politika důvěry, která vyžaduje github-hosted, job odmítne.

Účtuje mi GitHub dál minuty, když používám jiného poskytovatele runnerů?

Ne za joby, které přesunete. Runnery třetích stran se u GitHubu registrují jako self-hosted runnery a GitHub u self-hosted runnerů neúčtuje poplatky za minutu. GitHub dál účtuje licence, úložiště, které drží nad rámec zahrnutého limitu, a joby ponechané na runnerech hostovaných na GitHubu. Poskytovatel účtuje své vlastní minuty.

Jak připnout image runneru, aby se mi nezměnil pod rukama?

ubuntu-latest se posouvá podle harmonogramu GitHubu a ubuntu-24.04 připíná vydání operačního systému, ale ne verze balíčků v něm. Připněte to, na čem záleží, uvnitř jobu: setup actions s explicitními verzemi a image kontejnerů podle digestu. Zeptejte se každého poskytovatele, co vám dovolí připnout; samotná aplikace runneru se musí aktualizovat, aby dál fungovala s GitHubem.

Jak jsou joby na runneru třetí strany od sebe izolované?

Poskytovatelé se liší. Zeptejte se, zda každý job dostane vlastní virtuální stroj, nebo kontejner na sdíleném hostiteli, zda se stroj po jobu zničí a co si poskytovatel ponechává. Nový virtuální stroj pro každý job je nejsilnější z běžných modelů, protože z jednoho jobu nic nezůstane pro další.

Jak poskytovatele runnerů nejdřív otestovat na jednom repozitáři?

Nainstalujte GitHub App poskytovatele na jeden repozitář, přepněte jeden často spouštěný linuxový job přes proměnnou repozitáře ve větvi, spusťte ho alespoň desetkrát a porovnejte dobu trvání, dobu ve frontě, zásahy cache, selhání a náklady s výchozím stavem na runnerech hostovaných na GitHubu. Vrátíte se změnou proměnné.