GitHub Actions eller GitLab CI? Samme pipeline kan tage dobbelt så lang tid

Et offentliggjort forsøg med en Docker-baseret Django-app på AWS EC2 målte cirka 1 minut og 53 sekunder med GitHub Actions mod 3 minutter og 51 sekunder med GitLab CI. GitLab-kørslen tog dermed lidt mere end dobbelt så lang tid for denne arbejdsopgave. Forsøget målte de konkrete pipelines, ikke en hastighedsforskel, der gælder alle projekter.

For et team er det bedste udgangspunkt den CI/CD-løsning, der passer til kodeplatformen og den runner, teamet vil bruge. Sammenlign derefter tiden fra start til færdig udrulning med forbruget af fakturerbare jobminutter. Cache, køtid og parallelle jobs kan ændre de to tal på forskellige måder, mens en egen runner flytter en del af udgiften til teamets drift.

Hvad indgik i Django-forsøget?

Begge forløb testede applikationen, byggede et Docker-image og udrullede det til EC2. I Actions-forløbet blev imaget lagt i Docker Hub og derefter hentet ved udrulningen. Den målte tid dækker altså mere end selve Python-testene: installation af afhængigheder, imagebygning, overførsel og opstart kan hver især påvirke resultatet.

GitLab-forløbet brugte en offentlig runner, og forsøget beskriver både runneropsætning og cache som mulige forklaringer på forskellen. Det isolerer ikke virkningen af CI-platformen ved at holde hardware, cachetilstand og jobkonfiguration ens. En pipeline med andre afhængigheder eller uden udrulning kan derfor få et andet tidsforhold. Den nyttige læring er, at samme arbejdsopgave kan få meget forskellig gennemløbstid, selv om begge tjenester kan udføre den.

Hvad koster tiden på GitHub Actions?

GitHubs faktureringsregler angiver 0,006 dollar pr. minut for en standard Linux-runner med to kerner og 0,010 dollar for en tilsvarende Windows-runner. GitHubs eksempel med 5.000 minutter ud over den inkluderede kvote, fordelt på 3.000 Linux-minutter og 2.000 Windows-minutter, giver 38 dollar. Regnestykket gælder hostede runners; egne runners bruger ifølge de samme regler ikke Actions-minutkvoten.

GitHubs oversigt over runnerpriser præciserer, at hvert jobs forbrug rundes op til hele minutter. I et udtrykkeligt hypotetisk eksempel ville ét betalt Linux-job på 113 sekunder derfor tælle som to minutter og koste 0,012 dollar. Fordeles det samme arbejde på flere korte jobs, sker afrundingen for hvert job. Forsøgets samlede gennemløbstid kan ikke bruges som faktura, fordi den ikke viser den fakturerbare varighed af hvert enkelt job.

GitLab tæller compute-minutter på en anden måde

GitLabs regler for compute-minutter beregner hvert jobs forbrug som køretid i sekunder divideret med 60 og ganget med en omkostningsfaktor. Tid i statussen pending tæller ikke som jobkørsel. For en almindelig hostet Linux-runner på GitLab.com er faktoren 1 i størrelsen small og 2 i størrelsen medium; faktoren angiver forbrug af kvoten, ikke en pris i dollar.

GitLabs prisoplysning om ekstra compute-minutter angiver 10 dollar for 1.000 købte minutter, som kan bruges i op til et år. Det svarer til 0,010 dollar pr. minut, hvis hele pakken bliver brugt. I et hypotetisk enkelt job på 231 sekunder med faktor 1 ville forbruget være 3,85 compute-minutter, svarende til 0,0385 dollar af en fuldt udnyttet pakke. Det er ikke en målt pris for Django-forsøget: Den offentliggjorte tid er pipelinens gennemløbstid, mens GitLabs kvote belastes efter de enkelte jobs.

Hvorfor cache, kø og parallelisering ændrer sammenligningen

En varm cache kan spare download og installation af afhængigheder eller genbrug af Docker-lag. Gevinsten afhænger af, hvad der faktisk ligger i cachen, og om næste job får adgang til det. En sammenligning mellem en varm kørsel på den ene platform og en kold på den anden måler derfor også cachetilstand. Tilsvarende kan forskellige runnerstørrelser flytte tid fra bygning til betaling: En større runner kan afslutte arbejdet hurtigere, men bruge minutkvoten hurtigere.

Køtid er en anden del af udviklerens ventetid end jobkørsel. Et job kan stå klar til start, mens det venter på ledig kapacitet; den ventetid indgår i gennemløbet, men ikke nødvendigvis i compute-forbruget. Når uafhængige tests kører samtidig, kan resultatet komme tidligere, selv om summen af jobminutter vokser. Derfor skal teamet holde to mål adskilt: tiden til et brugbart resultat og summen af det arbejde, runnerne udfører.

Kodeplatform og egen runner ændrer også prisen

Ligger kode, rettigheder og gennemgang allerede i GitHub, er Actions tæt på teamets eksisterende arbejdsgang. Det tilsvarende gælder GitLab CI for et projekt, der allerede bruger GitLab. Den praktiske fordel er færre forbindelser mellem kodeplatform og CI-opsætning; den kan spare vedligeholdelsestid, selv hvis jobkørslerne koster omtrent det samme. Et platformsvalg alene siger dog intet om kapaciteten på den runner, som udfører arbejdet.

Begge tjenester kan bruge runners på teamets egen infrastruktur. Det giver kontrol over maskinens kapacitet, netværksadgang og installerede værktøjer, men teamet skal også stå for opdateringer, adgangsstyring og ledig kapacitet. At en egen runner ikke belaster den samme hostede minutkvote, gør den ikke gratis: Cloudmaskine eller fysisk udstyr og arbejdstid hører med i regnestykket. Ved sporadiske jobs kan tomgang fylde mere end prisen for selve kørslerne.

Sådan bliver sammenligningen brugbar for jeres pipeline

Kør samme commit, testkommandoer, afhængigheder, Dockerfile og udrulningsmål på begge platforme. Notér operativsystem, runnerstørrelse og om hvert job bruger en hostet eller egen runner. Det gør det muligt at se, om en tidsforskel følger CI-opsætningen eller blot forskellige maskiner.

1. Mål separat ventetid før jobstart, køretid for hvert job og tid til færdig pipeline. Gem også jobopdelingen, så de fakturerbare minutter kan beregnes efter den enkelte tjenestes regler.
2. Gentag kørsler med kold og varm cache. Notér, hvilke afhængigheder og Docker-lag der blev genbrugt, så cachegevinsten ikke bliver forvekslet med en generel hastighedsforskel.
3. Gentag målingen under almindelig belastning, og sammenlign flere kørsler frem for ét heldigt gennemløb. Nedbrudte downloads eller en optaget runner kan ellers dominere resultatet.
4. Læg samtidige jobs sammen i prisregnestykket, men brug tidspunktet for det sidste nødvendige job, når teamets ventetid vurderes. Medregn opsætning og drift, hvis valget kræver en egen runner.

Hvis en løsning stadig er hurtigere eller billigere, når disse forhold er gjort sammenlignelige, har teamet et grundlag for at vælge den. Hvis forskellen forsvinder, kan integrationen med kodeplatformen og arbejdet med at vedligeholde pipelinen være de afgørende forhold.

Læs også:

• Proton Mail eller Tuta? Mailklienten kan afgøre mere end krypteringen
• Aktiesparekonto eller depot? 17 procent kommer med årlig skat
• Gumroad eller Lemon Squeezy: En vare til 10 dollar vender gebyret