GitHub Actions, nebo GitLab CI: účet mění minuty, cache i runner

Pro soukromý repozitář na srovnatelném hostovaném Linuxu vychází při stejně dlouhých jobech zpravidla levněji GitHub Actions. Podle pravidel účtování GitHub Actions zahrnuje GitHub Free 2 000 minut měsíčně a nadlimitní běh standardního dvoujádrového Linuxu stojí 0,006 USD za minutu. Účet však závisí na skutečném čase jednotlivých jobů, využití cache a zvoleném runneru.

GitLab CI může vyhovovat týmu, který již platí za GitLab nebo provozuje vlastní runnery. Podle pravidel compute minut GitLabu má GitLab.com Free 400 minut měsíčně a spotřeba jobu se počítá z jeho délky násobené koeficientem runneru; výchozí malý linuxový runner má koeficient 1. Při rozdílné délce pipeline nebo jiné velikosti stroje se proto může změnit i výsledek cenového srovnání.

Licence a výpočet jsou dvě položky rozpočtu

Platba za uživatele kupuje plán a jeho funkce; výpočetní minuty jsou společnou kapacitou účtu nebo skupiny, nikoli měsíčním přídělem pro každého vývojáře. Ceník GitHubu uvádí u plánu Team cenu 4 USD za uživatele měsíčně v prvních 12 měsících a 3 000 zahrnutých minut měsíčně. Tým, kterému stačí funkce plánu Free, může platit pouze za překročené minuty; samotná vyšší spotřeba CI nevyžaduje nákup sedadel Team.

V ceníku GitLabu má Free limit 5 uživatelů v nadřazené skupině, Premium stojí 29 USD za uživatele měsíčně při roční platbě a zahrnuje 10 000 compute minut měsíčně; další kapacita na GitLab.com se prodává za 10 USD v balíčcích po 1 000 minutách. Zakoupené minuty se čerpají až po měsíční kvótě a nevyužitý zbytek přechází do dalšího měsíce. Porovnání plánů proto musí oddělit cenu potřebných funkcí a sedadel od ceny samotných jobů.

Tři podmíněné měsíční účty

Následující modely předpokládají soukromý repozitář, bezplatné plány, jeden job na pipeline a stejně dlouhý běh na hostovaném dvoujádrovém Linuxu. U GitLabu jde o výchozí malý runner s koeficientem 1; tým má nejvýše pět členů, nesdílí kvótu s dalšími projekty a nezačíná měsíc s dříve zakoupenými minutami. Částky v USD vyjadřují platbu za výpočet. Nezahrnují daně, úložiště ani provoz vlastní infrastruktury.

• Menší projekt: 100 spuštění po 5 minutách spotřebuje 500 minut. GitHub zůstane v zahrnuté kvótě a za výpočet zaplatí 0 USD. GitLab překročí svou kvótu o 100 minut, takže koupí jeden balíček za 10 USD; z koupené kapacity mu zbude 900 minut.
• Pravidelná integrace: 300 spuštění po 10 minutách spotřebuje 3 000 minut. GitHub zaplatí za 1 000 nadlimitních minut 6 USD. GitLab potřebuje po odečtení kvóty 2 600 minut, koupí tři balíčky za 30 USD a z koupených minut mu zbude 400.
• Intenzivní provoz: 1 000 spuštění po 10 minutách spotřebuje 10 000 minut. GitHub zaplatí za 8 000 nadlimitních minut 48 USD. GitLab potřebuje dalších 9 600 minut, takže koupí deset balíčků za 100 USD a 400 koupených minut mu zbude.

Zůstatek zakoupených minut GitLabu má hodnotu pro další provoz; uvedené částky představují nákup kapacity v daném měsíci, nikoli cenu každé skutečně spotřebované minuty. Pokud tým už platí za Premium, zahrnutá kvóta změní výpočet a do celkového účtu patří také licence. Modely se změní i tehdy, když jedna služba dokončí stejný job rychleji nebo pipeline obsahuje více jobů.

Stejný repozitář může běžet různě dlouho

V benchmarku Semaphore běžel testovací job repozitáře Redmine po zahřátí cache v průměru 9 minut 44 sekund na GitHub Actions a 11 minut 15 sekund na GitLabu; autoři provedli deset běhů na každé službě, použili stroje se dvěma virtuálními jádry a jediný job bez paralelního vykonávání. Shodná byla logika pipeline, verze nástrojů a testovaný repozitář, konfigurace strojů však nebyly zcela totožné. Měření zveřejnil dodavatel další služby CI a jeho výsledek popisuje právě tuto úlohu a konfiguraci.

Rozdíl v délce běhu se při opakování promítá do spotřebovaných minut. V hypotetickém provozu se stovkami spuštění měsíčně může čas strávený instalací závislostí, přípravou databáze a testy převážit rozdíl mezi nominálními sazbami. Zároveň je třeba rozlišovat dobu od spuštění pipeline do výsledku a součet času všech jejích jobů: paralelně běžící joby mohou zkrátit čekání vývojáře, ale jejich výpočet se do spotřeby sčítá.

Cache a vlastní runner mění podmínky

Zahřátá cache v benchmarku zachycuje opakovaný běh, při němž lze znovu využít uložené závislosti. První běh nebo změna klíče cache může vyžadovat jejich nové stažení a sestavení, takže poměr časů se může změnit. U GitHub Actions se navíc po překročení zahrnuté kapacity účtuje úložiště cache odděleně od minut. Výpočetní cena samotná proto nevystihuje dopad velké nebo často obnovované cache.

Vlastní runner přesouvá náklady z hostovaných minut na stroj, úložiště, síť a správu týmu. GitHub za běh na vlastním runneru minuty Actions neúčtuje; soukromý runner na GitLab.com nečerpá kvótu hostovaných compute minut. To však neříká, která volba je levnější: výsledek závisí na ceně a vytížení vlastní infrastruktury i na tom, zda stroj zvládne stejnou práci stejně rychle. Srovnávat hostovaný runner jedné služby s vlastním runnerem druhé bez těchto nákladů by zkreslilo účet.

Týdenní měření stejné pipeline

Pro rozhodnutí o vlastní zátěži stačí zaznamenat jeden pracovní týden srovnatelných běhů stejného commitu a stejné sady testů na obou službách. Záznam by měl obsahovat operační systém a velikost runneru, počet jobů, stav cache, čekání na runner, délku každého jobu a celkový čas do výsledku. Díky tomu lze oddělit spotřebu výpočtu od prodlevy, kterou pocítí vývojáři.

1. Spouštějte pipeline se stejnými verzemi nástrojů a zaznamenejte zvlášť běhy se zahřátou cache a běhy, při nichž se musí obnovit.
2. Sečtěte čas všech jobů; u hostovaných runnerů GitLabu jej převeďte koeficientem konkrétního typu stroje. Vedle spotřeby uveďte typickou i delší dobu celé pipeline.
3. Z četnosti běhů odvoďte měsíční spotřebu, odečtěte kvótu zvoleného plánu a připočtěte příslušnou platbu za další výpočet. Licence, úložiště a případný vlastní runner ponechte jako samostatné náklady.

Jestliže se pořadí služeb obrátí při prázdné cache, jiné velikosti runneru nebo po započtení již placeného plánu, právě tato podmínka rozhoduje o použitelnosti výsledku pro tým.

Přečtěte si také:

• Lokální LLM, nebo cloud: levnější volbu mění vytížení
• RAG, nebo fine-tuning: častá záměna prodraží firemní AI
• Claude Code, nebo Codex: benchmark nezná váš repozitář