GitHub Actions eller GitLab CI: när lagringen avgör

För ett litet team med privat kodförråd kan GitHub Actions ge lägre kostnad för hostade Linuxjobb när byggartefakterna är små och sparas kort tid. Om samma jobb lämnar stora artefakter som sparas länge kan GitLab CI bli billigare i den jämförelse av körning och lagring som räknas här. GitHubs debitering av Actions ger organisationer på Free 2 000 hostade minuter och 500 MB delat utrymme för artefakter och GitHub Packages; därutöver kostar en tvåkärnig Linux-runner 0,006 dollar per minut och lagring 0,25 dollar per GiB och månad.

GitLab.com Free har enligt GitLabs regler för compute-minuter 400 minuter per månad. Varje jobbs körtid multipliceras med runnerns kostnadsfaktor: en hostad Linux-runner i storleken small har faktor 1, medan medium har faktor 2. Två parallella jobb kan alltså bli klara snabbt men ändå förbruka summan av båda jobbens minuter. Det gör runnerstorlek, antal jobb och lagringstid viktigare för jämförelsen än enbart antalet pipelines.

Jobbminuter och väntetid mäter olika saker

En pipeline med två jobb som vart och ett kör i fem minuter förbrukar tio jobbminuter om kostnadsfaktorn är 1. Körs jobben samtidigt kan tiden till färdigt resultat bli kortare, men den debiterade jobbtiden blir inte fem minuter. Kötid är ytterligare en separat storhet: den påverkar när resultatet kommer, medan GitLabs compute-beräkning utgår från tiden då jobbet faktiskt kör.

Minuter utöver GitLabs fria kvot köps i paket. GitLabs prislista anger 10 dollar för 1 000 extra compute-minuter som engångsköp. Ett team som saknar köpt saldo behöver därför lägga ut för ett helt paket även om det bara saknas en del av paketets minuter. Oanvända köpta minuter kan föras vidare till en senare månad; paketköpet ska inte läsas som en ny månadsavgift. Kostnaden i exemplen nedan avser kontantutlägget när perioden börjar utan sådant saldo.

Operativsystem och runnerstorlek måste hållas fasta när priserna jämförs. GitHubs minutpris varierar mellan runner-typer, medan GitLabs kostnadsfaktor ändrar hur fort minutkvoten förbrukas. En kortare pipeline på en större runner kan därför kosta fler compute-minuter. Räknefallen använder samma antagna Linuxjobb på båda plattformarna och säger ingenting om vilken tjänst som skulle köra just dessa jobb snabbast i verkligheten.

Lagringen som inte ryms i minutpriset

På GitHub delar Actions-artefakter utrymme med GitHub Packages. Lagringen räknas timme för timme: när en artefakt raderas upphör framtida förbrukning, medan redan upplupen lagring finns kvar i periodens beräkning. Därför spelar både storleken på varje byggresultat och tiden det behålls roll. Ett team som använder det delade utrymmet för paket får dessutom mindre av den inkluderade mängden kvar till artefakter.

GitLab har en annan avgränsning. GitLabs regler för projektlagring anger 10 GiB på Free för Git-förråd och LFS; byggartefakter ingår inte i just den gränsen. Den siffran är alltså inte ett artefaktutrymme som kan ställas direkt mot GitHubs inkluderade mängd. Räknefallen förutsätter att GitLab-projektets kodförråd och LFS håller sig inom sin gräns och behandlar endast de angivna jobbens utdata som artefakter.

Det innebär inte att artefakter kan sparas utan hänsyn till andra villkor eller tekniska gränser. Här jämförs de publicerade Free-modellernas kostnad för hostad körning och den lagring som anges i deras debiteringsregler. Ett verkligt fakturaunderlag kan också omfatta andra tjänster och användningsmönster. Den avgränsningen är särskilt viktig när en pipeline producerar paket, containeravbilder eller cache utöver sina vanliga byggartefakter.

Tre villkorade fall för svenska team

Tre villkorade Linuxflöden där lång lagring av byggartefakter ändrar kostnadsjämförelsen mellan GitHub Actions och GitLab CI.

Alla tre fall är räkneexempel, inte uppmätta fakturor. Anta ett svenskt team med privat kodförråd på respektive Free-plan. Varje pipeline kör två hostade Linuxjobb som antas ta fem minuter vardera på båda tjänsterna. GitLab-jobben använder small-runnern med faktor 1; GitHub-jobben använder den tvåkärniga Linux-runnern. Perioden är 30 dagar, körningarna fördelas jämnt och den angivna artefaktmängden är storleken efter uppladdning. Lagringen antas ha nått ett jämnt läge: genomsnittlig mängd blir körningar per dag multiplicerat med artefaktstorlek och antal dagar den sparas.

GitHub anger sitt inkluderade utrymme som 500 MB och använder binära lagringsenheter i debiteringen. I beräkningen motsvarar det cirka 0,488 GiB, inte exakt 0,5 GiB. Beloppen nedan är avrundade till cent i dollar. Svensk moms, växelkurs, eventuella paket och annan infrastruktur ingår inte.

Litet flöde: Två pipelines per dag ger 600 jobbminuter under perioden. En artefakt på 0,1 GiB per pipeline, sparad i sju dagar, ger i jämnt läge 1,4 GiB i genomsnitt. GitHub håller sig inom minutkvoten och får cirka 0,23 dollar i beräknad lagringskostnad: (1,4 − 0,488) × 0,25. GitLab behöver 200 minuter utöver sin fria kvot och därmed ett paket för 10 dollar om köpt saldo saknas.
Fler körningar, kort lagring: Tio pipelines per dag ger 3 000 jobbminuter. Artefakter på 0,1 GiB som sparas i sju dagar ger 7 GiB i genomsnitt. GitHub får 1 000 betalda Linuxminuter, alltså 6 dollar, samt cirka 1,63 dollar för lagring: sammanlagt cirka 7,63 dollar. GitLab behöver 2 600 extra minuter och därmed tre paket för 30 dollar vid start utan saldo.
Stora artefakter: Fem pipelines per dag ger 1 500 jobbminuter. En artefakt på 0,6 GiB per pipeline som sparas i 30 dagar ger 90 GiB i genomsnitt. GitHubs minuter ryms i kvoten, men lagringen blir cirka 22,38 dollar: (90 − 0,488) × 0,25. GitLab behöver 1 100 extra minuter och därmed två paket för 20 dollar. I detta fall är GitLabs beräknade kontantutlägg lägre.

I det sista fallet ändras inga jobb om bara lagringstiden ändras. Med samma fem dagliga pipelines och samma artefaktstorlek ger 26 dagars bevaring i stället 78 GiB i genomsnitt och cirka 19,38 dollar på GitHub. Vid 27 dagar blir det 81 GiB och cirka 20,13 dollar. GitLabs paketbehov är fortfarande detsamma. Det visar hur en enda inställning för bevaring kan flytta kostnadsordningen runt paketpriset, trots oförändrad körtid.

Publicerat pipelineprov med hostade runners

Det publicerade pipelineprovet jämför sluttiden för GitHub Actions och GitLab CI på hostade runners.

I HinterBuilds publicerade prov med 100 körningar per plattform var den genomsnittliga sluttiden 8 minuter 42 sekunder för GitHub Actions och 7 minuter 18 sekunder för GitLab CI; genomsnittlig kötid var 12 respektive 8 sekunder. Pipelinen byggde en Docker-avbild, körde tester och distribuerade till Kubernetes under fem dagar. GitHub körde på ubuntu-latest och GitLab på saas-linux-medium-amd64, alltså två angivna hostade konfigurationer.

Resultatet gäller den pipelinen och de runner-valen. GitLabs medium-runner förbrukar compute-minuter snabbare än small-runnern i räknefallen, så provets sluttid kan inte läggas in som en allmän prisrabatt för GitLab. En egen runner skulle dessutom ge andra resurser och annan köbildning. För ett team som värderar snabb återkoppling kan några minuters väntan ändå vara betydelsefull, men den nyttan hör till teamets arbetsflöde och framgår inte av minutpriset.

Kodens hemvist och egna runners

Finns kod, granskning och behörigheter redan på GitHub är Actions ofta det enklaste valet för ett litet flöde. Motsvarande närhet mellan kodförråd och pipeline talar för GitLab CI när teamet redan arbetar i GitLab. Att flytta enbart CI-körningen kan kräva nya kopplingar för utlösare, åtkomst och status tillbaka till kodgranskningen. Det är arbetskostnader som de tre dollarjämförelserna inte mäter.

Med en egen runner flyttas körkostnaden i stället till teamets maskiner och drift. Då blir tillgänglig kapacitet för samtidiga jobb och den kö som uppstår när kapaciteten är upptagen centrala delar av valet. Plattformens kvot för hostade jobb är inte längre samma kostnadsmått, medan artefakter som fortfarande sparas hos plattformen måste bedömas separat. Ett kortare publicerat test på hostade runners avgör därför inte vad ett team får för körtid eller pris med sin egen infrastruktur.

Läs också: