Jak zmienić dostawcę runnerów GitHub Actions: etykiety, cache, sekrety, rozliczenia i fallback

Ten przewodnik jest neutralny wobec dostawców. Wyjaśnia, co się przenosi przy zmianie dostawcy runnerów GitHub Actions, co psuje się najczęściej i jak się wycofać. Tworzymy CRACI, jednego z dostawców; pojawia się tam, gdzie ma zastosowanie udokumentowany fakt, oraz we własnej sekcji na końcu. Aby najpierw wybrać dostawcę, zob. porównanie dostawców runnerów GitHub Actions i alternatywy dla runnerów hostowanych przez GitHub.

Co się zmienia, a co zostaje po przejściu

GitHub Actions składa się z dwóch części. GitHub to warstwa sterująca: przechowuje repozytorium i pliki workflow, uruchamia wyzwalacze, przechowuje sekrety, przydziela zadania, pokazuje logi i checki, przechowuje artefakty i wydaje tokeny OIDC. Runner CI to miejsce, w którym zadanie się wykonuje: maszyna z obrazem, CPU, dyskiem, ścieżką sieciową do internetu i zwykle lokalnym cache. GitHub przydziela zadanie runnerowi, dostarcza sekrety zadania na jego początku, a runner przesyła logi z powrotem.

Dostawca runnerów zastępuje tylko drugą część.

Element	Zostaje w GitHub	Przechodzi do dostawcy
Repozytorium, pliki workflow, wyzwalacze	Tak	Nie
Magazyn sekretów	Tak	Sekrety są dostarczane na maszynę dostawcy na początku zadania
Przydział zadań, logi, interfejs checków	Tak	Runner przesyła logi z powrotem
Artefakty z actions/upload-artifact	Tak	Nie
Wystawca tokenów OIDC	Tak	Nie, ale token wskazuje, że runner jest self-hosted
Maszyna, obraz, CPU, pamięć, dysk	Nie	Tak
Wychodząca ścieżka sieciowa i adresy IP	Nie	Tak
Magazyn cache	Zależy od dostawcy	Zależy od dostawcy
Rozliczanie za minutę przeniesionych zadań	Nie	Tak

Runner zewnętrznego dostawcy rejestruje się w GitHub jako runner self-hosted. Dlatego obowiązują go zasady GitHub dla runnerów self-hosted: jak etykiety kierują zadania, jak grupy runnerów ograniczają dostęp, jak opisuje go token OIDC i jak GitHub go rozlicza.

Zmiana runs-on i etykiety

GitHub szuka runnera pasującego do etykiet i grup runs-on zadania. Jeśli żaden pasujący runner nie jest online, zadanie czeka w kolejce, aż któryś się pojawi; jeśli przydzielony runner nie podejmie zadania w ciągu 60 sekund, trafia ono z powrotem do kolejki; a zadanie, które czeka w kolejce dłużej niż 24 godziny, kończy się niepowodzeniem (dokumentacja GitHub o runnerach self-hosted). Literówka w etykiecie albo aplikacja dostawcy niezainstalowana w repozytorium objawia się zadaniem, które nigdy się nie rozpoczyna.

Dostawcy określają maszynę na jeden z dwóch sposobów:

• W etykiecie. Ubicloud używa etykiet takich jak ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404, a Avrea avrea-ubuntu-latest-2-vcpu, z arm w etykiecie dla maszyn ARM. Zmiana rozmiaru oznacza zmianę etykiety.
• W kroku setup. CRACI używa jednej etykiety, runs-on: craci, a krok cracicorp/setup@v1 wybiera rozmiar (od 1 do 32 jednostek obliczeniowych po 1 vCPU i 3 GB, domyślnie 2), obraz, politykę sieciową albo szablon runnera organizacji według jego sluga. Jeśli CRACI nie może przetworzyć parametru, uruchamia domyślne środowisko i zapisuje ostrzeżenie w logu zadania; nieznany obraz lub szablon jest odrzucany.

Przełączanie jedną zmienną

Zamiast wpisywać etykietę na sztywno, warto umieścić ją w zmiennej repozytorium lub organizacji. Przejście w przód lub powrót to wtedy zmiana ustawień, a nie pull request w każdym repozytorium.

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

Wybór dotyczy pojedynczego zadania, więc zadania build i test mogą się przenieść, a zadanie deploy zostać. Zmienne można ustawić na poziomie organizacji i nadpisać w repozytorium, więc jedno ustawienie może przenieść grupę repozytoriów, a pojedyncze repozytorium może się wyłączyć.

Workflowy wielokrotnego użytku

Jeśli ten sam pipeline jest skopiowany do wielu repozytoriów, warto przenieść go do workflow wielokrotnego użytku, który odczytuje runner z parametru wejściowego lub zmiennej. Zmiana runs-on w tym miejscu zmienia każde repozytorium, które go wywołuje. Rulesety mogą wymagać uruchamiania workflow w repozytoriach organizacji, co utrzymuje w użyciu wspólną wersję.

Obrazy runnerów: zgodność i przypinanie

Hostowany obraz GitHub zawiera duży zestaw preinstalowanych narzędzi i hostowany tool cache. Dostawcy oferują obraz zgodny z obrazem GitHub albo lżejszy. Zadania często zależą od rzeczy, których nigdy nie deklarują:

• preinstalowanych wersji języków i narzędzi wiersza poleceń;
• sudo bez hasła oraz systemd dla usług uruchamianych przez systemctl;
• działającego demona Docker z Buildx i Compose;
• hostowanego tool cache, który akcje setup-* odczytują przed pobieraniem;
• wolnego miejsca na dysku dla dużych buildów.

Zasada: zacząć od obrazu dostawcy zgodnego z GitHub. Zadanie należy przenieść na lżejszy obraz dopiero wtedy, gdy przechodzi, i dodać jawne kroki setup-* dla wszystkiego, z czego korzystało niejawnie.

Przypinanie: ubuntu-latest przechodzi na nowe wydanie według harmonogramu GitHub, a ubuntu-24.04 przypina wydanie systemu operacyjnego, a nie wersje pakietów. Warto przypiąć to, co ważne, wewnątrz zadania: akcje setup z jawnymi wersjami i obrazy kontenerów przez digest. Należy zapytać każdego dostawcę, co pozwala przypiąć. Sama aplikacja runnera musi się stale aktualizować, aby komunikować się z GitHub.

W CRACI dostępne są obrazy CRACI Slim na x86-64 i ARM64 (Ubuntu 24.04, bez systemd) oraz pełny obraz Ubuntu 24.04 zgodny z GitHub Actions, wybierany jako ubuntu-24.04 lub ubuntu-latest, który podąża za obrazem runnera Ubuntu 24.04 GitHub i zawiera hostowany tool cache. Każdy obraz ma Docker Engine, Buildx i Compose v2.

Cache: co się przenosi, a co startuje od zera

Pierwsze uruchomienia u nowego dostawcy są często wolniejsze, a zwykłą przyczyną jest zimny cache, nie wolna maszyna. To, co Państwo zobaczą, zależy od działania actions/cache (README actions/cache):

• Wpis jest wyszukiwany po kluczu i wersji, czyli haszu ścieżek w cache i narzędzia kompresji.
• Wpisy mają zakres gałęzi; wpisy gałęzi domyślnej są dostępne dla innych gałęzi.
• Domyślnie repozytorium może przechowywać do 10 GB cache, zanim najstarsze wpisy zostaną usunięte. Administratorzy repozytorium oraz właściciele organizacji lub enterprise mogą podnieść limit; użycie powyżej 10 GB jest naliczane na konto (GitHub o dependency caching).
• Cache zapisany na Windows nie jest przywracany w innym systemie operacyjnym ani odwrotnie, chyba że ustawiono enableCrossOsArchive; inne narzędzie kompresji także daje inną wersję.

Dostawcy serwują cache na jeden z dwóch sposobów:

Model	Pierwsze uruchomienia	Kompromis
Runner korzysta z usługi cache GitHub, tak jak runnery hostowane przez GitHub	Istniejące wpisy są przywracane	Ruch cache przechodzi przez internet między dostawcą a GitHub
Dostawca serwuje API cache z magazynu obok swoich runnerów	Zwykle pusty, dopóki pierwsze uruchomienia go nie zapełnią, chyba że dostawca importuje wpisy GitHub lub sięga do nich, gdy brakuje własnych	Szybsze przywracanie; zapisane tam wpisy zwykle nie są widoczne dla runnerów hostowanych przez GitHub

Druga kwestia ma znaczenie przy mieszanej flocie i przy wycofaniu: jeśli przełączą Państwo zadanie z powrotem, również w GitHub może wystartować z zimnym cache. Warto zapytać, z którego modelu korzysta dostawca i gdzie przechowywane są wpisy.

Jak odróżnić zimny cache od wolnego runnera. Weźmy build Node, który zapisuje w cache duży katalog node_modules. Przy pierwszym uruchomieniu u nowego dostawcy actions/cache zgłasza chybienie, krok instalacji pobiera wszystko, a krok końcowy zapisuje cache. Od kolejnego uruchomienia na tej samej gałęzi krok zgłasza trafienie, a krok instalacji się skraca. Uruchomienia należy porównywać dopiero po rozgrzaniu cache: odczytać wyjście cache-hit i mierzyć krok przywracania oraz krok instalacji osobno od samego buildu. Klucze, zakresy i zatruwanie cache opisujemy w artykule jak działa cache GitHub Actions.

W CRACI actions/cache działa tak jak dziś, a zapis buildu oznacza dla każdego pakietu, czy został przywrócony z cache CI, zamiast zostać pobrany.

Cache warstw Dockera

Mechanizm	Gdzie są warstwy	Co warto wiedzieć
BuildKit type=gha	Cache GitHub Actions	Te same zasady zakresu i rozmiaru co wyżej; wymaga buildera, który go obsługuje
BuildKit type=registry	Osobny obraz w Państwa rejestrze	Działa na każdym runnerze i przetrwa zmianę dostawcy; płacą Państwo za przechowywanie i transfer w rejestrze
Lokalny cache warstw lub trwały dysk dostawcy	Obok runnerów dostawcy	Zwykle najszybszy; zostaje u dostawcy, gdy Państwo odejdą

Cache w rejestrze to opcja przenośna (backendy cache Dockera):

- 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

Dwa zadania startujące w tym samym momencie przywracają ten sam cache i oba budują brakujące warstwy. Dzieje się tak w każdym CI, więc nie należy tego traktować jako problemu dostawcy.

CRACI oferuje cache warstw kontenerów z lokalnym cache warstw, zdalnym cache warstw i cache bind mount.

Sekrety, OIDC i poświadczenia chmurowe

GitHub przechowuje Państwa sekrety i dostarcza je runnerowi, który wykonuje zadanie. Przeniesienie zadania do dostawcy oznacza powierzenie mu sekretów tego zadania. Warto zapytać:

• Czy każde zadanie otrzymuje własną maszynę wirtualną, czy kontener na współdzielonym hoście?
• Czy maszyna jest niszczona po zadaniu i czy cokolwiek jest zachowywane?
• Jakie logi przechowuje dostawca? GitHub maskuje zarejestrowane sekrety w logach zadań i zaznacza, że automatyczne ukrywanie nie jest gwarantowane dla przekształconych wartości; warto zapytać także o własne logi systemowe dostawcy.

OIDC nadal działa, z jednym haczykiem. Token OIDC wydaje GitHub, nie runner, więc permissions: id-token: write działa na każdym runnerze. Jednak claim runner_environment w tokenie ma wartość github-hosted lub self-hosted (dokumentacja GitHub o OIDC), a na runnerze zewnętrznego dostawcy jest to self-hosted. Polityka zaufania w chmurze, która wymaga github-hosted, odrzuca zadanie. Przykładem jest pula workload identity w Google Cloud z takim warunkiem atrybutu:

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

Usunięcie sprawdzenia runnera poszerza krąg tych, którzy mogą uzyskać poświadczenia, więc jednocześnie należy zaostrzyć inny warunek. Przed zmianą warto przeszukać każdą politykę zaufania w chmurze i konfigurację workload identity pod kątem runner_environment.

Wypychanie obrazów: GITHUB_TOKEN z packages: write wypycha obrazy do GitHub Container Registry z każdego runnera, a logowania do rejestrów korzystające z zapisanych sekretów działają bez zmian.

W CRACI aplikacja GitHub odczytuje Państwa kod i uruchomienia Actions oraz zarządza runnerami, które rejestruje dla Państwa organizacji. Każde zadanie działa we własnej, odizolowanej maszynie wirtualnej, a CRACI nie przechowuje Państwa kodu źródłowego.

Tożsamość sieciowa: listy dozwolonych IP i ruch wychodzący

Nowy runner łączy się z nowych adresów IP. Warto spisać wszystko, co filtruje według adresu źródłowego:

• listy dozwolonych adresów baz danych i repozytoriów artefaktów;
• API SaaS z ograniczeniami IP;
• serwery SFTP partnerów i usługi wewnętrzne za firewallem.

Opcje to statyczne lub stałe wychodzące adresy IP dostawcy albo proxy pod Państwa kontrolą. To także moment, aby zdecydować, z czym zadania w ogóle mogą się łączyć: polityka ruchu wychodzącego na runnerze nie pozwala skompromitowanej zależności wysłać sekretów na host, którego build nigdy nie potrzebował. Zob. polityka ruchu wychodzącego w GitHub Actions.

CRACI oferuje stały zakres wychodzących adresów IP i politykę ruchu wychodzącego, z domyślnym blokowaniem lub zezwalaniem, która jest walidowana przed startem zadania i w razie błędu blokuje ruch. Bez parametru network domyślny szablon zezwala na inne połączenia wychodzące, więc kontrolę ruchu wychodzącego trzeba skonfigurować.

Mieszana flota: Linux się przenosi, macOS i iOS zostają

Runner wybiera się dla każdego zadania osobno, więc jeden workflow może uruchamiać zadania Linux u dostawcy, a zadania macOS na runnerach hostowanych przez GitHub. Artefakty przesłane przez actions/upload-artifact przechowuje GitHub, więc zadanie na jednym runnerze może przekazać pliki zadaniu na innym.

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

Zadania pozostawione w GitHub nadal korzystają z użycia wliczonego w Państwa plan, a powyżej niego rozlicza je GitHub. CRACI uruchamia dziś Linux na x86-64 i ARM64, a Windows i macOS są na roadmapie, więc mieszana flota z CRACI oznacza CRACI dla Linuksa i runnery hostowane przez GitHub dla reszty.

Fallback, gdy dostawca nie działa

GitHub nie ma wbudowanego fallbacku między etykietami runnerów. Jeśli żaden runner dla danej etykiety nie jest online, zadanie czeka, a po 24 godzinach kończy się niepowodzeniem. Warto się na to przygotować:

• Przełącznik w zmiennej opisany wyżej: po ustawieniu z powrotem na ubuntu-latest nowe uruchomienia trafiają na runnery hostowane przez GitHub.
• Ręczne nadpisanie dla pilnych uruchomień: parametr workflow_dispatch odczytywany jako runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes w zadaniach, aby zawieszone zadanie nie blokowało wdrożenia na godziny.
• Monitorowanie czasu w kolejce, aby zauważyć, gdy zadania czekają dłużej niż zwykle.

Warto zapytać każdego dostawcę, czy oferuje automatyczny fallback i co go uruchamia. Należy też uwzględnić kierunek odwrotny: GitHub kolejkuje i przydziela każde zadanie, więc awaria GitHub Actions zatrzymuje zadania także u każdego dostawcy runnerów.

Rozliczenia: czy GitHub nadal pobiera opłaty?

GitHub nie pobiera opłat za minutę za runnery self-hosted, a runnery zewnętrznych dostawców rejestrują się jako self-hosted, więc przeniesione minuty znikają z rachunku GitHub (rozliczenia GitHub Actions). GitHub nadal rozlicza:

• licencje użytkowników w Państwa planie;
• przechowywanie artefaktów i cache powyżej wliczonego limitu;
• zadania pozostawione na runnerach hostowanych przez GitHub, powyżej użycia wliczonego w plan, które nie jest zwracane.

W czasie pilotażu płacą Państwo dwie faktury. Dostawcy liczą minuty buildu różnie: GitHub zaokrągla każde zadanie w górę do pełnej minuty, a niektórzy dostawcy naliczają co sekundę. Aby oszacować użycie przed zmianą i po niej, warto skorzystać z kalkulatora kosztów GitHub Actions. CRACI pobiera opłaty tylko za minuty buildu: $0.002 za vCPU-minutę ($0.004 za domyślny runner 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej.

Izolacja bezpieczeństwa: o co pytać każdego dostawcę

Pytanie	Dlaczego to ważne
Jedna maszyna wirtualna na zadanie czy kontenery na współdzielonym hoście?	Współdzielony host pozwala skompromitowanemu zadaniu dosięgnąć sąsiadów
Czy maszyna jest niszczona po zadaniu?	Trwała maszyna przenosi pliki, poświadczenia i procesy do następnego zadania
Gdzie jest sprzęt i kto go obsługuje?	Lokalizacja danych, jurysdykcja i umowy z Państwa klientami
Co dostawca przechowuje i jak długo?	Logi, cache i dane sieciowe mogą zawierać wrażliwe informacje
Jakie certyfikaty posiada?	Zapyta o to Państwa ocena dostawców
Czy można kontrolować ruch wychodzący?	Uniemożliwia wyciek sekretów przez złośliwy pakiet
Co jego aplikacja GitHub może odczytywać i zmieniać?	Uprawnienia aplikacji obowiązują w każdym repozytorium, w którym ją Państwo zainstalują

GitHub podaje, że runnerów self-hosted prawie nigdy nie należy używać w repozytoriach publicznych, bo każdy może otworzyć pull request i skompromitować środowisko, oraz że runnery just-in-time wykonują najwyżej jedno zadanie, zanim zostaną usunięte (dokumentacja GitHub o bezpiecznym użyciu). Nowa maszyna wirtualna dla każdego zadania odpowiada na większość tych obaw.

Odpowiedzi CRACI: każde zadanie działa we własnej, odizolowanej maszynie wirtualnej na europejskiej infrastrukturze bare-metal. System zarządzania bezpieczeństwem informacji CRACI Corporation Oy w zakresie rozwoju i obsługi platformy CRACI ma certyfikat ISO/IEC 27001 wydany przez Into Certification, a szczegóły są w Trust Center. CRACI przechowuje metadane buildów, dane pakietów, ślady sieciowe, SBOM-y, provenance, cache i zapisy audytowe, ale nigdy Państwa kodu źródłowego. Zob. do czego CRACI ma dostęp i bezpieczeństwo.

Najpierw próba na jednym repozytorium

1. Wybrać repozytorium z reprezentatywnym, często uruchamianym workflow Linux, a nie pipeline wydań.
2. Zapisać punkt odniesienia na runnerach hostowanych przez GitHub: medianę czasu trwania i czasu w kolejce z ostatnich 30 uruchomień oraz rozliczone minuty.
3. Zainstalować aplikację GitHub dostawcy tylko w tym repozytorium.
4. Przełączyć jedno zadanie przez zmienną repozytorium, na gałęzi.
5. Uruchomić je co najmniej dziesięć razy, a pierwsze trzy odrzucić jako rozgrzewanie cache.
6. Porównać czas trwania, czas w kolejce, wskaźnik trafień w cache, błędy i koszt; sprawdzić logi, OIDC i połączenia wychodzące.
7. Wycofać zmianę przez zmianę zmiennej i potwierdzić, że zadanie wraca na runnery hostowane przez GitHub.

Metryka	Punkt odniesienia GitHub	Dostawca	Próg zaliczenia
Mediana czasu trwania zadania			Państwa cel, na przykład o 30% krócej
Mediana czasu w kolejce			Nie gorzej niż punkt odniesienia
Wskaźnik trafień w cache po rozgrzaniu			Taki sam jak punkt odniesienia
Nieudane uruchomienia niespowodowane kodem			Brak
Koszt uruchomienia			Poniżej punktu odniesienia
OIDC, listy dozwolonych adresów i połączenia wychodzące			Wszystko działa

Szybkość warto mierzyć na własnym workflow. Każdy dostawca publikuje własne dane, a jedyną liczbą, która rozstrzyga w Państwa przypadku, jest ta z Państwa pipeline'u.

Gdzie pasuje CRACI

CRACI to runner GitHub Actions. Zastępuje runner, a nie GitHub Actions: zadanie przenosi się przez runs-on: craci, rozmiary i obrazy ustawia się przez cracicorp/setup@v1 lub szablon runnera organizacji, a uruchomienia nadal są widoczne w GitHub. CRACI wykonuje buildy mniej więcej dwa razy szybciej niż runnery hostowane przez GitHub dzięki szybszemu sprzętowi, krótszemu czasowi w kolejce i cache.

Powodem, by wybrać go zamiast innych dostawców, jest to, co zostawia po sobie każde zadanie: SBOM tego, co build pobrał, ze stanem kompletności, zarejestrowany w ramach polityki ruchu wychodzącego, która w razie błędu blokuje ruch. docs.craci.com oferuje też prompt dla agentów kodujących, który proponuje plan migracji Państwa workflowów zadanie po zadaniu. Zob. integracja z CI/CD.

Kiedy CRACI nie jest odpowiedzią

• Potrzebują Państwo runnerów macOS lub Windows: są na roadmapie CRACI.
• Korzystają Państwo z GitHub Enterprise Server, którego CRACI nie obsługuje.
• Państwa CI to GitLab CI lub Jenkins: oba są na roadmapie.
• Runnery muszą działać na Państwa własnym koncie w chmurze: runnery hostowane przez klienta są na roadmapie. RunsOn i opcja bring-your-own-cloud w WarpBuild robią to już dziś; zob. CRACI vs RunsOn i CRACI vs WarpBuild.
• Głównym celem jest obserwowalność i debugowanie CI; zob. CRACI vs Avrea. O utrzymywaniu własnych runnerów piszemy w artykule runnery zarządzane a self-hosted.

Zmiana dostawcy runnerów: najczęstsze pytania

Co trzeba zmienić, aby korzystać z innego dostawcy runnerów GitHub Actions?

Należy zainstalować aplikację GitHub dostawcy, a następnie zmienić etykietę runs-on zadania na etykietę dostawcy. Workflowy, wyzwalacze, sekrety i interfejs GitHub pozostają bez zmian. Zanim przeniosą Państwo ważne zadania, warto sprawdzić obraz runnera, cache, wychodzące adresy IP, polityki zaufania w chmurze oparte na OIDC, fallback i rozliczenia.

Czy cache GitHub Actions przechodzi do nowego dostawcy runnerów?

To zależy od tego, skąd dostawca serwuje cache. Jeśli jego runnery korzystają z usługi cache GitHub, istniejące wpisy są przywracane. Jeśli serwuje API cache z magazynu obok swoich runnerów, cache zwykle startuje pusty i zapełnia się przy pierwszych uruchomieniach. Warto zapytać dostawcę, z którego modelu korzysta i czy wpisy zapisane na jego runnerach są widoczne dla runnerów hostowanych przez GitHub.

Czy cache warstw Dockera działa na runnerach zewnętrznych dostawców?

Tak, przy użyciu jednego z trzech mechanizmów: backendu type=gha w BuildKit, który korzysta z cache Actions; cache w rejestrze z type=registry, działającego na każdym runnerze; albo cache warstw lub trwałego dysku, które dostawca utrzymuje obok swoich runnerów.

Czy buildy macOS i iOS mogą zostać na GitHub, gdy zadania Linux zostaną przeniesione?

Tak. Runner wybiera się dla każdego zadania osobno, więc zadania Linux mogą działać u dostawcy, a zadania macOS pozostać na runnerach hostowanych przez GitHub w tym samym workflow. Łączy się je przez needs:, a pliki przekazuje za pomocą actions/upload-artifact i actions/download-artifact, które przechowuje GitHub.

Co dzieje się z zadaniem, gdy runner zewnętrznego dostawcy nie działa? Czy jest fallback?

GitHub nie ma wbudowanego fallbacku między etykietami runnerów. Zadanie, którego etykiety nie pasują do żadnego runnera online, pozostaje w kolejce i po 24 godzinach kończy się niepowodzeniem. Warto trzymać etykietę w zmiennej repozytorium lub organizacji, aby powrót wymagał jednej zmiany, ustawić timeout-minutes i zapytać każdego dostawcę, czy oferuje własny fallback.

Czy sekrety i OIDC działają na runnerach zewnętrznych dostawców?

Tak. GitHub przechowuje sekrety i dostarcza je runnerowi na początku zadania, a token OIDC wydaje GitHub, więc id-token: write działa na każdym runnerze. Haczyk: claim runner_environment w tokenie ma na runnerze zewnętrznego dostawcy wartość self-hosted, więc polityka zaufania w chmurze wymagająca github-hosted odrzuca zadanie.

Czy GitHub nadal nalicza opłaty za minuty, gdy korzystam z innego dostawcy runnerów?

Nie za przeniesione zadania. Runnery zewnętrznych dostawców rejestrują się w GitHub jako runnery self-hosted, a GitHub podaje, że runnery self-hosted nie są objęte opłatami za minutę. GitHub nadal rozlicza licencje użytkowników, przechowywane dane powyżej wliczonego limitu i zadania pozostawione na runnerach hostowanych przez GitHub. Dostawca rozlicza własne minuty.

Jak przypiąć obraz runnera, aby nie zmieniał się bez mojej wiedzy?

ubuntu-latest zmienia się według harmonogramu GitHub, a ubuntu-24.04 przypina wydanie systemu operacyjnego, ale nie wersje pakietów. Warto przypiąć to, co ważne, wewnątrz zadania: akcje setup z jawnymi wersjami i obrazy kontenerów przez digest. Należy zapytać każdego dostawcę, co pozwala przypiąć; sama aplikacja runnera musi się aktualizować, aby nadal współpracować z GitHub.

Jak zadania są od siebie odizolowane na runnerze zewnętrznego dostawcy?

Dostawcy się różnią. Warto zapytać, czy każde zadanie otrzymuje własną maszynę wirtualną, czy kontener na współdzielonym hoście, czy maszyna jest niszczona po zadaniu i co dostawca zachowuje później. Nowa maszyna wirtualna dla każdego zadania to najsilniejszy z popularnych modeli, bo nic z jednego zadania nie zostaje dla następnego.

Jak najpierw przetestować dostawcę runnerów na jednym repozytorium?

Należy zainstalować aplikację GitHub dostawcy w jednym repozytorium, przełączyć jedno często uruchamiane zadanie Linux przez zmienną repozytorium na gałęzi, uruchomić je co najmniej dziesięć razy i porównać czas trwania, czas w kolejce, trafienia w cache, błędy i koszt z punktem odniesienia na runnerach hostowanych przez GitHub. Wycofanie to zmiana zmiennej.