Näin vaihdat GitHub Actions -runneripalvelua: tunnisteet, välimuistit, salaisuudet, laskutus ja varajärjestely

Tämä opas on toimittajaneutraali. Se kertoo, mikä siirtyy, kun vaihdat GitHub Actions -runneripalvelua, mikä useimmiten hajoaa ja miten perääntyä. Me kehitämme CRACI:a, joka on yksi palveluntarjoajista; se mainitaan siellä, missä dokumentoitu tosiasia pätee, ja omassa osiossaan lopussa. Jos haluat ensin valita palveluntarjoajan, katso GitHub Actions -runneripalvelut vertailussa ja vaihtoehdot GitHubin ylläpitämille runnereille.

Mikä muuttuu ja mikä pysyy, kun vaihdat

GitHub Actionsissa on kaksi puoliskoa. GitHub on ohjaustaso: se tallentaa repositorion ja työnkulkutiedostot, laukaisee triggerit, tallentaa salaisuudet, jakaa jobit, näyttää lokit ja checkit, säilyttää artefaktit ja myöntää OIDC-tokenit. CI-runneri on paikka, jossa jobi suoritetaan: kone, jossa on levykuva, prosessori, levy, verkkoyhteys internetiin ja yleensä paikallinen välimuisti. GitHub osoittaa jobin runnerille, toimittaa jobin salaisuudet sen alkaessa, ja runneri striimaa lokit takaisin.

Runneripalvelu korvaa vain jälkimmäisen puoliskon.

Kohde	Pysyy GitHubissa	Siirtyy palveluntarjoajalle
Repositorio, työnkulkutiedostot, triggerit	Kyllä	Ei
Salaisuuksien säilö	Kyllä	Salaisuudet toimitetaan palveluntarjoajan koneelle jobin alkaessa
Jobien jako, lokit, checkien käyttöliittymä	Kyllä	Runneri striimaa lokit takaisin
Artefaktit actions/upload-artifact-actionista	Kyllä	Ei
OIDC-tokenin myöntäjä	Kyllä	Ei, mutta token kertoo runnerin olevan self-hosted
Kone, levykuva, prosessori, muisti, levy	Ei	Kyllä
Lähtevän liikenteen reitti ja IP-osoitteet	Ei	Kyllä
Välimuistin tallennustila	Riippuu palveluntarjoajasta	Riippuu palveluntarjoajasta
Siirrettyjen jobien minuuttilaskutus	Ei	Kyllä

Kolmannen osapuolen runneri rekisteröityy GitHubiin itse ylläpidettynä runnerina. Siksi siihen pätevät GitHubin säännöt itse ylläpidetyille runnereille: miten tunnisteet ohjaavat jobeja, miten runner-ryhmät rajaavat pääsyä, miten OIDC-token kuvaa sitä ja miten GitHub laskuttaa sitä.

runs-on-muutos ja tunnisteet

GitHub etsii runnerin, joka vastaa jobin runs-on-tunnisteita ja -ryhmiä. Jos yhtään vastaavaa runneria ei ole verkossa, jobi pysyy jonossa, kunnes sellainen tulee verkkoon; jos osoitettu runneri ei ota jobia vastaan 60 sekunnin kuluessa, se palautetaan jonoon; ja jobi, joka on jonossa yli 24 tuntia, epäonnistuu (GitHubin self-hosted runner -viite). Kirjoitusvirhe tunnisteessa tai palveluntarjoajan sovellus, jota ei ole asennettu repositorioon, näkyy jobina, joka ei koskaan käynnisty.

Palveluntarjoajat ilmaisevat koneen kahdella tavalla:

• Tunnisteessa. Ubicloud käyttää tunnisteita kuten ubicloud-standard-2, Blacksmith blacksmith-2vcpu-ubuntu-2404 ja Avrea avrea-ubuntu-latest-2-vcpu, ja ARM-koneilla tunnisteessa on arm. Koon vaihtaminen tarkoittaa tunnisteen vaihtamista.
• Setup-vaiheessa. CRACI käyttää yhtä tunnistetta, runs-on: craci, ja cracicorp/setup@v1-vaihe valitsee koon (1–32 laskentayksikköä, joissa kussakin 1 vCPU ja 3 Gt, oletus 2), levykuvan, verkkokäytännön tai organisaation runner-mallin sen slugin perusteella. Jos CRACI ei pysty jäsentämään syötettä, se ajaa oletusympäristön ja kirjoittaa varoituksen jobin lokiin; tuntematon levykuva tai malli hylätään.

Tee vaihdosta yksi muuttuja

Laita tunniste repositorio- tai organisaatiotason muuttujaan sen sijaan, että kovakoodaisit sen. Eteen- tai taaksepäin vaihtaminen on silloin asetusmuutos eikä pull request jokaiseen repositorioon.

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

Valinta tehdään jobikohtaisesti, joten build- ja testijobit voivat siirtyä, kun käyttöönottojobi jää. Muuttujat voi asettaa organisaatiotasolla ja ohittaa repositoriokohtaisesti, joten yksi asetus voi siirtää joukon repositorioita ja yksi repositorio voi jättäytyä pois.

Uudelleenkäytettävät työnkulut

Jos sama putki on kopioitu moneen repositorioon, siirrä se uudelleenkäytettävään työnkulkuun (reusable workflow), joka lukee runnerin syötteestä tai muuttujasta. runs-on-arvon muuttaminen siellä muuttaa jokaisen sitä kutsuvan repositorion. Rulesetit voivat vaatia työnkulun ajamista organisaation repositorioissa, mikä pitää jaetun version käytössä.

Runnerien levykuvat: yhteensopivuus ja kiinnittäminen

GitHubin hostatussa levykuvassa on laaja esiasennettu työkalusto ja hostattu työkaluvälimuisti. Palveluntarjoajat tarjoavat joko GitHubin kanssa yhteensopivan levykuvan tai kevyemmän. Jobit riippuvat usein asioista, joita ne eivät koskaan ilmoita:

• esiasennetuista kieliversioista ja komentorivityökaluista;
• salasanattomasta sudo:sta ja systemd:stä palveluille, jotka käynnistetään systemctl:llä;
• käynnissä olevasta Docker-daemonista, Buildxistä ja Composesta;
• hostatusta työkaluvälimuistista, jonka setup-*-actionit lukevat ennen latausta;
• vapaasta levytilasta suuria buildeja varten.

Päätössääntö: aloita palveluntarjoajan GitHub-yhteensopivalla levykuvalla. Siirrä jobi kevyeen levykuvaan vasta, kun se on vihreä, ja lisää eksplisiittiset setup-*-vaiheet kaikelle, mitä se käytti implisiittisesti.

Kiinnittäminen: ubuntu-latest siirtyy uuteen julkaisuun GitHubin aikataulussa, ja ubuntu-24.04 kiinnittää käyttöjärjestelmän julkaisun, ei sen pakettiversioita. Kiinnitä tärkeät asiat jobin sisällä: setup-actionit eksplisiittisillä versioilla ja konttikuvat digestillä. Kysy jokaiselta palveluntarjoajalta, mitä se antaa kiinnittää. Itse runner-sovelluksen on päivityttävä jatkuvasti, jotta se voi kommunikoida GitHubin kanssa.

CRACI:ssa levykuvat ovat CRACI Slim x86-64- ja ARM64-arkkitehtuureille (Ubuntu 24.04 ilman systemd:tä) sekä täysi GitHub Actionsin kanssa yhteensopiva Ubuntu 24.04 -levykuva, joka valitaan arvolla ubuntu-24.04 tai ubuntu-latest, joka seuraa GitHubin Ubuntu 24.04 -runnerin levykuvaa ja sisältää hostatun työkaluvälimuistin. Jokaisessa levykuvassa on Docker Engine, Buildx ja Compose v2.

Välimuistit: mikä siirtyy ja mikä alkaa kylmänä

Ensimmäiset ajot uudella palveluntarjoajalla ovat usein hitaampia, ja tavallinen syy on kylmä välimuisti, ei hidas kone. Se, miten actions/cache toimii, ratkaisee, mitä näet (actions/cache README):

• Merkintä löydetään sen avaimen ja version perusteella; versio on tiiviste välimuistiin tallennetuista poluista ja pakkaustyökalusta.
• Merkinnät on rajattu haaroittain; oletushaaran merkinnät ovat muiden haarojen käytettävissä.
• Oletuksena repositoriossa voi olla enintään 10 Gt välimuisteja, ennen kuin vanhimmat merkinnät poistetaan. Repositorioiden ylläpitäjät sekä organisaation tai yrityksen omistajat voivat nostaa rajaa; 10 Gt:n ylittävä käyttö laskutetaan tililtä (GitHubin riippuvuuksien välimuisti).
• Windowsissa tallennettua välimuistia ei palauteta toisessa käyttöjärjestelmässä eikä päinvastoin, ellei enableCrossOsArchive ole asetettu; eri pakkaustyökalu antaa myös eri version.

Palveluntarjoajat tarjoilevat välimuistin kahdella tavalla:

Malli	Ensimmäiset ajot	Kompromissi
Runneri käyttää GitHubin välimuistipalvelua, kuten GitHubin ylläpitämät runnerit	Olemassa olevat merkinnät palautuvat	Välimuistiliikenne kulkee internetin yli palveluntarjoajan ja GitHubin välillä
Palveluntarjoaja tarjoilee välimuisti-API:n runnereidensa vieressä olevasta tallennustilasta	Yleensä tyhjä, kunnes ensimmäiset ajot täyttävät sen, ellei palveluntarjoaja tuo GitHubin merkintöjä tai käytä niitä varalla	Nopeammat palautukset; siellä kirjoitetut merkinnät eivät yleensä näy GitHubin ylläpitämille runnereille

Jälkimmäinen kohta on tärkeä sekakalustoille ja peruutukselle: jos vaihdat jobin takaisin, se voi alkaa kylmänä myös GitHubissa. Kysy, mitä mallia palveluntarjoaja käyttää ja missä merkinnät ovat.

Kylmän välimuistin erottaminen hitaasta runnerista. Otetaan Node-buildi, joka tallentaa välimuistiin suuren node_modules-hakemiston. Ensimmäisellä ajolla uudella palveluntarjoajalla actions/cache raportoi hudin, asennusvaihe lataa kaiken ja jälkivaihe tallentaa välimuistin. Seuraavasta samassa haarassa tehdystä ajosta alkaen vaihe raportoi osuman ja asennusvaihe lyhenee. Vertaa ajoja vasta, kun välimuisti on lämmin: lue cache-hit-tuloste ja ajoita palautusvaihe ja asennusvaihe erikseen itse buildista. Avaimista, rajauksista ja välimuistin myrkyttämisestä kerrotaan sivulla miten GitHub Actionsin välimuisti toimii.

CRACI:ssa actions/cache toimii kuten nytkin, ja buildin tallenne merkitsee pakettikohtaisesti, palautettiinko paketti CI-välimuistista sen sijaan, että se haettiin.

Docker-kerrosten välimuisti

Mekanismi	Missä kerrokset ovat	Mitä on hyvä tietää
BuildKit type=gha	GitHub Actionsin välimuisti	Samat rajaus- ja kokosäännöt kuin yllä; tarvitsee builderin, joka tukee sitä
BuildKit type=registry	Erillinen konttikuva rekisterissäsi	Toimii millä tahansa runnerilla ja säilyy palveluntarjoajan vaihdossa; maksat rekisterin tallennuksesta ja siirroista
Palveluntarjoajan paikallinen kerrosvälimuisti tai pysyvä levy	Palveluntarjoajan runnereiden vieressä	Yleensä nopein; jää jälkeen, jos lähdet palveluntarjoajalta

Rekisterivälimuisti on siirrettävä vaihtoehto (Dockerin välimuistin taustajärjestelmät):

- 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

Kaksi samaan aikaan alkavaa jobia palauttavat saman välimuistin ja buildaavat molemmat siitä puuttuvat kerrokset. Näin tapahtuu missä tahansa CI:ssä, joten älä tulkitse sitä palveluntarjoajan ongelmaksi.

CRACI tarjoaa konttikerrosten välimuistin paikallisella kerrosvälimuistilla, etäkerrosvälimuistilla ja bind mount -välimuistilla.

Salaisuudet, OIDC ja pilvitunnukset

GitHub tallentaa salaisuutesi ja toimittaa ne sille runnerille, joka ajaa jobin. Jobin siirtäminen palveluntarjoajalle tarkoittaa, että luotat tuon jobin salaisuudet palveluntarjoajalle. Kysy:

• Saako jokainen jobi oman virtuaalikoneen vai kontin jaetulla isännällä?
• Tuhotaanko kone jobin jälkeen, ja säilytetäänkö mitään?
• Mitä lokeja palveluntarjoaja säilyttää? GitHub peittää rekisteröidyt salaisuudet jobien lokeissa ja sanoo, ettei automaattista peittämistä taata muunnetuille arvoille; kysy myös palveluntarjoajan omista järjestelmälokeista.

OIDC toimii edelleen, yhdellä varauksella. GitHub myöntää OIDC-tokenin, ei runneri, joten permissions: id-token: write toimii millä tahansa runnerilla. Tokenin runner_environment-claim on kuitenkin github-hosted tai self-hosted (GitHubin OIDC-viite), ja kolmannen osapuolen runnerilla se on self-hosted. Pilven luottamuskäytäntö, joka vaatii arvon github-hosted, hylkää jobin. Esimerkiksi Google Cloudin workload identity pool, jossa on tämä attribuuttiehto:

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

Runner-tarkistuksen poistaminen laajentaa sitä, kuka voi saada tunnukset, joten tiukenna samalla jotain toista ehtoa. Ennen vaihtoa etsi jokaisesta pilven luottamuskäytännöstä ja workload identity -määrityksestä runner_environment.

Konttikuvien pushaaminen: GITHUB_TOKEN, jolla on packages: write, pushaa GitHub Container Registryyn miltä tahansa runnerilta, ja tallennettuja salaisuuksia käyttävät rekisterikirjautumiset toimivat ennallaan.

CRACI:ssa GitHub App lukee koodisi ja Actions-ajosi ja hallinnoi runnereita, jotka se rekisteröi organisaatiollesi. Jokainen jobi ajetaan omassa eristetyssä virtuaalikoneessaan, eikä CRACI tallenna lähdekoodiasi.

Verkkoidentiteetti: IP-sallintalistat ja lähtevä liikenne

Uusi runneri lähtee liikkeelle uusista IP-osoitteista. Listaa kaikki, mikä suodattaa lähdeosoitteen perusteella:

• tietokantojen ja artefaktirepositorioiden sallintalistat;
• IP-rajoitetut SaaS-API:t;
• kumppanien SFTP-palvelimet ja palomuurin takana olevat sisäiset palvelut.

Vaihtoehdot ovat palveluntarjoajan staattiset tai vakaat lähtevän liikenteen IP-osoitteet tai hallitsemasi välityspalvelin (proxy). Nyt on myös hetki päättää, mihin jobit ylipäätään saavat ottaa yhteyttä: runnerin egress-käytäntö estää kompromissoitua riippuvuutta lähettämästä salaisuuksia palvelimelle, jota buildi ei koskaan tarvinnut. Katso GitHub Actionsin egress-käytäntö.

CRACI tarjoaa vakaan lähtevän liikenteen IP-alueen sekä egress-käytännön, oletuksena estävän tai sallivan, joka validoidaan ennen jobin alkua ja toimii fail closed -periaatteella. Ilman network-syötettä oletusmalli sallii muut lähtevät yhteydet, joten lähtevän liikenteen hallinta on jotain, minkä määrität itse.

Sekakalusto: siirrä Linux, pidä macOS ja iOS paikallaan

Runneri valitaan jobikohtaisesti, joten yksi työnkulku voi ajaa Linux-jobinsa palveluntarjoajalla ja macOS-jobinsa GitHubin ylläpitämillä runnereilla. actions/upload-artifact-actionilla ladatut artefaktit tallentaa GitHub, joten yhden runnerin jobi voi välittää tiedostoja toisen runnerin jobille.

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

GitHubiin jätetyt jobit kuluttavat yhä tilauksesi sisältämää käyttöä, ja GitHub laskuttaa sen ylittävän osan. CRACI ajaa tänään Linuxia x86-64- ja ARM64-arkkitehtuureilla, ja Windows ja macOS ovat tiekartalla, joten sekakalusto CRACI:n kanssa tarkoittaa CRACI:a Linuxille ja GitHubin ylläpitämiä runnereita lopuille.

Varajärjestely, kun palveluntarjoaja on alhaalla

GitHubissa ei ole sisäänrakennettua varajärjestelyä runner-tunnisteiden välillä. Jos yhtään tunnisteen runneria ei ole verkossa, jobi odottaa ja epäonnistuu 24 tunnin kuluttua. Varaudu siihen:

• Muuttujakytkin yllä: aseta se takaisin arvoon ubuntu-latest, niin uudet ajot menevät GitHubin ylläpitämille runnereille.
• Manuaalinen ohitus kiireellisille ajoille: workflow_dispatch-syöte, joka luetaan muodossa runs-on: ${{ inputs.runner || vars.LINUX_RUNNER || 'ubuntu-latest' }}.
• timeout-minutes jobeille, jotta jumiin jäänyt jobi ei pidätä käyttöönottoa tuntikausia.
• Jonotusajan seuranta, jotta huomaat, kun jobit odottavat tavallista kauemmin.

Kysy jokaiselta palveluntarjoajalta, tarjoaako se automaattisen varajärjestelyn ja mikä sen laukaisee. Varaudu myös toiseen suuntaan: GitHub jonouttaa ja jakaa jokaisen jobin, joten GitHub Actionsin katko pysäyttää jobit myös jokaisella runneripalvelulla.

Laskutus: veloittaako GitHub yhä?

GitHub ei veloita minuuttimaksua itse ylläpidetyistä runnereista, ja kolmansien osapuolten runnerit rekisteröityvät itse ylläpidettyinä, joten siirtämäsi minuutit lakkaavat näkymästä GitHubin laskussa (GitHub Actionsin laskutus). GitHub laskuttaa yhä:

• tilauksesi käyttäjäpaikat;
• sisältyvän kiintiön ylittävän artefaktien ja välimuistin tallennuksen;
• GitHubin ylläpitämille runnereille jätetyt jobit tilauksesi sisältämän käytön ylittäviltä osin; käyttämätöntä kiintiötä ei hyvitetä.

Kokeilun aikana maksat kaksi laskua. Palveluntarjoajat laskevat build-minuutit eri tavoin: GitHub pyöristää jokaisen jobin ylöspäin täyteen minuuttiin, ja jotkin palveluntarjoajat mittaavat sekunneittain. Mitoita käyttösi ennen ja jälkeen GitHub Actionsin kustannuslaskurilla. CRACI veloittaa vain build-minuuteista: $0.002 vCPU-minuutilta ($0.004 oletuksena olevalta 2 vCPU:n runnerilta), mitattuna sekunneittain, ilman kuukausimaksua.

Tietoturvaeristys: mitä kysyä keneltä tahansa palveluntarjoajalta

Kysymys	Miksi sillä on väliä
Yksi virtuaalikone jobia kohden vai kontteja jaetulla isännällä?	Jaetulla isännällä kompromissoitu jobi pääsee naapureihinsa
Tuhotaanko kone jobin jälkeen?	Pysyvä kone kuljettaa tiedostoja, tunnuksia ja prosesseja seuraavaan jobiin
Missä laitteisto on, ja kuka sitä operoi?	Tietojen sijainti, lainkäyttöalue ja asiakkaidesi sopimukset
Mitä palveluntarjoaja tallentaa, ja kuinka pitkäksi aikaa?	Lokit, välimuistit ja verkkotiedot voivat sisältää arkaluonteista aineistoa
Mitkä sertifioinnit sillä on?	Toimittaja-arviointisi kysyy niitä
Voitko hallita lähtevää liikennettä?	Estää salaisuuksia vuotamasta haitallisen paketin kautta
Mitä sen GitHub App voi lukea ja muuttaa?	Sovelluksen oikeudet koskevat jokaista repositoriota, johon sen asennat

GitHubin mukaan itse ylläpidettyjä runnereita ei pitäisi juuri koskaan käyttää julkisille repositorioille, koska kuka tahansa voi avata pull requestin ja kompromissoida ympäristön, ja just-in-time-runnerit ajavat enintään yhden jobin ennen kuin ne poistetaan (GitHubin turvallisen käytön viite). Tuore virtuaalikone jokaiselle jobille vastaa suurimpaan osaan tästä huolesta.

CRACI:n vastaukset: jokainen jobi ajetaan omassa eristetyssä virtuaalikoneessaan eurooppalaisella bare metal -infrastruktuurilla. CRACI Corporation Oy:n tietoturvallisuuden hallintajärjestelmä CRACI-alustan kehittämisen ja operoinnin osalta on ISO/IEC 27001 -sertifioitu, sertifioijana Into Certification, ja tiedot ovat Trust Centerissä. CRACI tallentaa buildien metatiedot, pakettitiedot, verkkojäljet, SBOM:t, alkuperätiedot, välimuistit ja audit-kirjaukset, mutta ei koskaan lähdekoodiasi. Katso mihin CRACI pääsee ja tietoturva.

Koeaja ensin yhdellä repositoriolla

1. Valitse repositorio, jossa on edustava, usein ajettava Linux-työnkulku, ei julkaisuputki.
2. Kirjaa lähtötaso GitHubin ylläpitämillä runnereilla: mediaanikesto ja -jonotusaika viimeisimmiltä 30 ajolta sekä laskutetut minuutit.
3. Asenna palveluntarjoajan GitHub App vain tähän repositorioon.
4. Vaihda yksi jobi repositoriomuuttujan kautta haarassa.
5. Aja se vähintään kymmenen kertaa ja jätä kolme ensimmäistä huomiotta välimuistin lämmittelynä.
6. Vertaa kestoa, jonotusaikaa, välimuistin osumaprosenttia, epäonnistumisia ja kustannuksia; tarkista lokit, OIDC ja lähtevät kutsut.
7. Palaa takaisin vaihtamalla muuttuja ja varmista, että jobi palaa GitHubin ylläpitämille runnereille.

Mittari	GitHub-hosted-lähtötaso	Palveluntarjoaja	Hyväksymisraja
Jobin mediaanikesto			Oma tavoitteesi, esimerkiksi 30 % lyhyempi
Mediaanijonotusaika			Ei huonompi kuin lähtötaso
Välimuistin osumaprosentti lämmittelyn jälkeen			Sama kuin lähtötaso
Epäonnistuneet ajot, jotka eivät johdu koodista			Ei yhtään
Kustannus ajoa kohden			Alle lähtötason
OIDC, sallintalistat ja lähtevät kutsut			Kaikki toimivat

Mittaa nopeus omalla työnkulullasi. Jokainen palveluntarjoaja julkaisee omat lukunsa, ja ainoa luku, joka ratkaisee sinun tapauksesi, on oman putkesi luku.

Miten CRACI sopii kuvaan

CRACI on GitHub Actions -runneri. Se korvaa runnerin, ei GitHub Actionsia: jobi siirretään runs-on: craci -rivillä, koot ja levykuvat asetetaan cracicorp/setup@v1:llä tai organisaation runner-mallilla, ja ajot näkyvät yhä GitHubissa. CRACI ajaa buildit noin kaksi kertaa nopeammin kuin GitHubin ylläpitämät runnerit nopeamman laitteiston, lyhyempien jonotusaikojen ja välimuistin ansiosta.

Syy valita se muiden palveluntarjoajien sijaan on se, mitä kustakin jobista jää jäljelle: SBOM siitä, mitä buildi haki, kattavuustilan kanssa, tallennettuna fail closed -periaatteella toimivan egress-käytännön alaisena. docs.craci.com tarjoaa myös koodausagenteille kehotteen, joka ehdottaa työnkuluillesi jobikohtaisen siirtosuunnitelman. Katso CI/CD-integraatio.

Milloin CRACI ei ole vastaus

• Tarvitset macOS- tai Windows-runnereita: ne ovat CRACI:n tiekartalla.
• Käytät GitHub Enterprise Serveriä, jota CRACI ei tue.
• CI:si on GitLab CI tai Jenkins: molemmat ovat tiekartalla.
• Runnereiden on oltava omalla pilvitililläsi: asiakkaan ylläpitämät runnerit ovat tiekartalla. RunsOn ja WarpBuildin bring-your-own-cloud-vaihtoehto tekevät sen jo nyt; katso CRACI vs. RunsOn ja CRACI vs. WarpBuild.
• Päätavoitteesi on CI:n havainnoitavuus ja vianetsintä; katso CRACI vs. Avrea. Omien runnereiden ajamisesta kerrotaan sivulla hallinnoidut vs. itse ylläpidetyt runnerit.

Runneripalvelun vaihtaminen: usein kysytyt kysymykset

Mitä minun pitää muuttaa, jotta voin käyttää toista GitHub Actions -runneripalvelua?

Asenna palveluntarjoajan GitHub App ja vaihda sitten jobin runs-on-tunniste palveluntarjoajan tunnisteeseen. Työnkulut, triggerit, salaisuudet ja GitHubin käyttöliittymä pysyvät ennallaan. Ennen kuin siirrät tärkeitä jobeja, tarkista runnerin levykuva, välimuistit, lähtevät IP-osoitteet, OIDC:tä käyttävät pilven luottamuskäytännöt, varajärjestely ja laskutus.

Siirtyvätkö GitHub Actions -välimuistini uudelle runneripalvelulle?

Se riippuu siitä, mistä palveluntarjoaja tarjoilee välimuistin. Jos sen runnerit käyttävät GitHubin välimuistipalvelua, olemassa olevat merkinnät palautuvat. Jos se tarjoilee välimuisti-API:n runnereidensa vieressä olevasta tallennustilasta, välimuisti on yleensä aluksi tyhjä ja täyttyy ensimmäisillä ajoilla. Kysy palveluntarjoajalta, kumpaa mallia se käyttää ja näkyvätkö sen runnereilla kirjoitetut merkinnät GitHubin ylläpitämille runnereille.

Toimiiko Docker-kerrosten välimuisti kolmansien osapuolten runnereilla?

Kyllä, millä tahansa kolmesta mekanismista: BuildKitin type=gha-taustajärjestelmällä, joka käyttää Actions-välimuistia; rekisterivälimuistilla type=registry, joka toimii millä tahansa runnerilla; tai kerrosvälimuistilla tai pysyvällä levyllä, jota palveluntarjoaja pitää runnereidensa vieressä.

Voinko pitää macOS- ja iOS-buildit GitHubissa ja siirtää Linux-jobit?

Kyllä. Runneri valitaan jobikohtaisesti, joten Linux-jobit voivat toimia palveluntarjoajalla, kun macOS-jobit pysyvät GitHubin ylläpitämillä runnereilla samassa työnkulussa. Yhdistä ne needs:-avaimella ja välitä tiedostot actions/upload-artifact- ja actions/download-artifact-actioneilla, joiden tiedostot GitHub tallentaa.

Mitä jobille tapahtuu, jos kolmannen osapuolen runneri on alhaalla? Onko varajärjestelyä?

GitHubissa ei ole sisäänrakennettua varajärjestelyä runner-tunnisteiden välillä. Jobi, jonka tunnistetta mikään verkossa oleva runneri ei vastaa, jää jonoon ja epäonnistuu 24 tunnin kuluttua. Pidä tunniste repositorio- tai organisaatiotason muuttujassa, jotta takaisin vaihtaminen on yksi muutos, aseta timeout-minutes ja kysy jokaiselta palveluntarjoajalta, tarjoaako se oman varajärjestelyn.

Toimivatko salaisuudet ja OIDC yhä kolmansien osapuolten runnereilla?

Kyllä. GitHub tallentaa salaisuudet ja toimittaa ne runnerille jobin alkaessa, ja GitHub myöntää OIDC-tokenin, joten id-token: write toimii millä tahansa runnerilla. Mutta: tokenin runner_environment-claim on kolmannen osapuolen runnerilla self-hosted, joten pilven luottamuskäytäntö, joka vaatii arvon github-hosted, hylkää jobin.

Laskuttaako GitHub yhä minuuteista, jos käytän toista runneripalvelua?

Ei siirtämistäsi jobeista. Kolmansien osapuolten runnerit rekisteröityvät GitHubiin itse ylläpidettyinä runnereina, ja GitHubin mukaan itse ylläpidetyistä runnereista ei veloiteta minuuttimaksuja. GitHub laskuttaa yhä käyttäjäpaikat, sisältyvän kiintiön ylittävän tallennustilan ja GitHubin ylläpitämille runnereille jätetyt jobit. Palveluntarjoaja laskuttaa omat minuuttinsa.

Miten kiinnitän runnerin levykuvan, jotta se ei muutu yllättäen?

ubuntu-latest vaihtuu GitHubin aikataulussa, ja ubuntu-24.04 kiinnittää käyttöjärjestelmän julkaisun mutta ei sen pakettiversioita. Kiinnitä tärkeät asiat jobin sisällä: setup-actionit eksplisiittisillä versioilla ja konttikuvat digestillä. Kysy jokaiselta palveluntarjoajalta, mitä se antaa kiinnittää; itse runner-sovelluksen on päivityttävä, jotta se toimii GitHubin kanssa.

Miten jobit eristetään toisistaan kolmannen osapuolen runnerilla?

Palveluntarjoajat eroavat toisistaan. Kysy, saako jokainen jobi oman virtuaalikoneen vai kontin jaetulla isännällä, tuhotaanko kone jobin jälkeen ja mitä palveluntarjoaja säilyttää jälkikäteen. Tuore virtuaalikone jokaiselle jobille on yleisistä malleista vahvin, koska yhdestä jobista ei jää mitään seuraavalle.

Miten testaan runneripalvelua ensin yhdellä repositoriolla?

Asenna palveluntarjoajan GitHub App yhteen repositorioon, vaihda yksi usein ajettava Linux-jobi repositoriomuuttujan kautta haarassa, aja se vähintään kymmenen kertaa ja vertaa kestoa, jonotusaikaa, välimuistiosumia, epäonnistumisia ja kustannuksia GitHubin ylläpitämän runnerin lähtötasoon. Palaa takaisin vaihtamalla muuttuja.