GitHub of GitLab: wanneer eigen runners zwaarder wegen

Voor een klein privaat project op gehoste runners biedt GitHub Actions op Free doorgaans meer inbegrepen capaciteit. De facturatieregels van GitHub noemen 2.000 Actions-minuten per maand voor standaardrunners, gedeeld door de repositories van dezelfde accounteigenaar; eigen runners tellen niet mee en standaardrunners zijn gratis voor openbare repositories. Die voorsprong zegt minder over de kosten zodra een team zelf rekenkracht levert.

Op GitLab.com Free krijgt een namespace volgens de GitLab-documentatie 400 compute-minuten per maand op instance runners; de looptijd van iedere taak wordt vermenigvuldigd met een kostfactor, bij de standaard kleine Linux-runner één en bij de middelgrote twee. Voor gehoste uitvoering met vergelijkbare taakduur ligt GitHub dus voor de hand. Bij eigen runners maken vooral machinekosten, beheer en wachttijd het verschil. De quota gelden bovendien op een ander niveau: bij GitHub voor de accounteigenaar, bij GitLab voor de bovenliggende namespace.

Taakminuten en doorlooptijd zijn twee maten

Een CI-pipeline kan verschillende taken tegelijk uitvoeren. Het verbruik is de som van hun afzonderlijke looptijden, terwijl de ontwikkelaar wacht op de laatste taak die voor een bruikbaar resultaat nodig is. In een voorwaardelijk voorbeeld kosten een build van vijftien minuten en tests van tien minuten samen vijfentwintig taakminuten als ze parallel lopen, ook wanneer het resultaat na ongeveer vijftien minuten beschikbaar is. Starten de tests pas na de build, dan wordt de wachttijd ongeveer vijfentwintig minuten.

Een extra testmatrix of controle bij een merge request kan het maandverbruik verhogen zonder de wachttijd even sterk te verlengen. Het omgekeerde kan ook: een trage eindtaak houdt een wijziging op, terwijl de overige taken weinig capaciteit vragen. Bij GitLab telt wachttijd in de rij niet als jobduur voor compute-minuten; voor het team is die wachttijd uiteraard wel merkbaar. Daarom horen in een vergelijking zowel verbruik per maand als tijd tot een bruikbare uitslag.

Een klein privaat project doorgerekend

Neem een voorwaardelijk voorbeeld zonder ander verbruik op hetzelfde account of in dezelfde namespace. Een project draait twintig pipelines per maand met telkens een Linux-build van vijftien minuten en een testtaak van tien minuten. Dat levert twintig maal vijfentwintig, dus vijfhonderd taakminuten op. Op een standaard gehoste Linux-runner van GitHub blijft dit binnen de inbegrepen ruimte, met vijftienhonderd minuten over.

Op de kleine GitLab Linux-runner valt hetzelfde werk met kostfactor één honderd compute-minuten boven de inbegrepen ruimte. Als de taken op een middelgrote runner even lang zouden duren, verdubbelt het verbruik door factor twee tot duizend compute-minuten. Zo’n grotere machine kan de uitvoering versnellen; om hetzelfde quotaverbruik te bereiken, moet ze de taakduur minstens halveren. Een snelheidswinst is dus niet automatisch een besparing op compute-minuten.

De rekenuitkomst staat of valt met het werk dat een team werkelijk draait. Een mislukte taak gebruikt de minuten tot het moment van stoppen; een nieuwe poging voegt weer verbruik toe. Ook andere private repositories onder dezelfde eigenaar of namespace doen een beroep op de beschikbare ruimte. Voor een team met meerdere projecten is de drukste pipeline daarom geen goede maat voor het maandverbruik.

Eigen runners verplaatsen de rekening

Bij eigen runners leveren teams de machine zelf. De GitLab-prijspagina vermeldt dat uitvoering op eigen runners geen compute-minuten verbruikt en ook na het opgebruiken van de gehoste quota kan doorgaan; voor een private groep op GitLab.com Free noemt zij bovendien een limiet van vijf gebruikers. Ook bij GitHub vallen eigen runners buiten de minutenbundel. De ruimere GitHub-bundel heeft dan minder gewicht, maar repositoryhosting en eventuele abonnementskosten blijven meetellen.

Stel als tweede voorwaardelijk voorbeeld dat een team honderd pipelines per maand draait, met per pipeline een build van twintig minuten en tests van tien minuten. Dat zijn drieduizend taakminuten. Als alle taken op eigen runners draaien, gebruiken ze bij geen van beide platforms de gehoste minutenbundel. De uitvoering vraagt wel rekenkracht, opslag, netwerkverkeer en tijd voor onderhoud, updates en toegangsbeheer. Een bestaande machine kan die extra belasting opvangen; een nieuw ingerichte runner heeft een andere kostenbasis.

Ook de doorlooptijd kan verschuiven. Eén eigen runner verwerkt gelijktijdig aangeboden taken niet vanzelf parallel; zonder vrije capaciteit ontstaat een wachtrij. Meer runners kunnen die rij verkorten, maar verhogen de kosten van machines die soms ongebruikt klaarstaan. De vergelijking moet daarom bezette én ongebruikte capaciteit en beheertijd omvatten. Waar een team de runner onderbrengt, bepaalt bovendien de netwerkroute naar broncode, pakketregisters en artefacten.

Wat een gemeten snelheidsverschil zegt

De openbare benchmark van SocialGouv noteert bij overdracht van grote bestanden vanaf data.gouv.fr 20 ‘mb/s’ voor een gehoste GitHub-runner en meer dan 100 ‘mb/s’ voor de geteste zelfbeheerde GitLab-opstelling op Azure Kubernetes Service in Frankrijk; de resultaten voor afzonderlijke taken verschillen eveneens per opstelling en cache-instelling. De README licht de schrijfwijze van de eenheid niet verder toe. De meting vergelijkt verschillende infrastructuur en netwerkpaden, zodat het verschil niet aan het CI-platform alleen kan worden toegeschreven.

Overdracht is bovendien maar een deel van de pipeline. Bij grote downloads kan de netwerkroute bepalend zijn; bij een test die vooral rekent of op een vrije runner wacht, liggen de knelpunten elders. Een bestaande benchmark maakt die variabelen zichtbaar, maar levert geen vaste snelheidsrangorde op voor andere projecten.

Welke keuze past bij de werklast?

Voor een klein privaat project met standaard gehoste Linux-taken en weinig beheerwens is GitHub Actions meestal de eenvoudige uitgangspositie: de voorbeeldwerklast past ruim binnen de bundel. GitLab CI/CD komt sterker in beeld wanneer het team al geschikte runners beheert, de uitvoeromgeving zelf wil bepalen of de bestaande GitLab-repositories en samenwerking een migratie overbodig maken. Bij eigen capaciteit verdwijnen de genoemde minuten uit de directe platformrekening, maar de kosten van die capaciteit niet.

Het omslagpunt hangt af van de eigen taakmix. De maandelijkse som van joblooptijden laat zien hoeveel gehoste capaciteit nodig is; de tijd van een wijziging tot de laatste benodigde uitslag laat zien wat ontwikkelaars merken. Bij GitLab verandert de kostfactor het eerste getal. Bij eigen runners komen machinekosten, beheer en wachtrijen in beeld. Samen bepalen die posten of inbegrepen minuten voor een team werkelijk het zwaarst wegen.