GitHub Actions o CircleCI: costi e tempi diversi

Per scegliere tra GitHub Actions e CircleCI, il prezzo di un minuto Linux è solo il punto di partenza: contano il costo di una pipeline completata e il tempo che passa dall’avvio al risultato. Due classi con la stessa tariffa nominale possono impiegare tempi diversi perché assegnano risorse diverse ai job; quando le esecuzioni arrivano insieme, si aggiunge l’attesa in coda.

Una pipeline con un solo job mette soprattutto alla prova la velocità di quel job. Con molte pipeline simultanee, invece, la capacità di avviare job in parallelo può incidere sul tempo di risposta anche quando i minuti di calcolo consumati restano identici. Per confrontare le piattaforme servono quindi due misure distinte: costo per esecuzione e tempo totale fino al risultato.

Il prezzo del minuto dipende dalla classe scelta

La tabella dei runner GitHub indica 0,006 dollari al minuto per Linux x64 a due core, 0,010 per Windows x64 a due core e 0,062 per il runner macOS standard; GitHub arrotonda per eccesso al minuto intero la durata fatturabile di ogni job. Una pipeline con job paralleli può dunque terminare rapidamente e accumulare comunque molti minuti fatturabili. Anche i job brevi vanno conteggiati separatamente, perché l’arrotondamento si applica a ciascuno.

Nel listino CircleCI, il piano Performance include 30.000 crediti gratuiti e vende quelli aggiuntivi a 15 dollari per 25.000; l’esempio Linux Medium usa 10 crediti al minuto, pari a 3.000 minuti per 30.000 crediti. Dai crediti aggiuntivi risulta un costo marginale di 0,006 dollari per minuto su quella classe: coincide con la tariffa Linux GitHub citata sopra, ma l’uguaglianza di prezzo non implica uguaglianza di CPU, memoria o durata del job. CircleCI usa inoltre crediti per utenti attivi e funzioni aggiuntive, che vanno tenuti fuori dal costo del solo calcolo.

Le regole di fatturazione GitHub Actions prevedono minuti inclusi nei piani per repository privati e l’uso gratuito dei runner standard nei repository pubblici; i runner più grandi restano a pagamento anche quando sono disponibili minuti inclusi. La tariffa marginale aiuta a confrontare due job, mentre la spesa mensile effettiva dipende anche dalle quote del proprio account e dagli addebiti per l’archiviazione.

Prima di confrontare i tempi, normalizzare le risorse

Il nome della classe non basta a descrivere la capacità di un runner. Per ogni job occorre affiancare architettura, sistema operativo, vCPU, memoria e tipo di executor: un test limitato dalla memoria può cambiare sensibilmente durata anche a parità di core. Se una piattaforma offre soltanto una classe più capiente per il carico desiderato, il confronto utile è tra le classi che si acquisterebbero davvero, riportando sia il loro prezzo sia il tempo ottenuto.

La stessa attenzione vale per ciò che accade prima e dopo i test. Installazione delle dipendenze, preparazione del database, ripristino della cache e caricamento degli artefatti possono occupare quote diverse del job sulle due piattaforme. Una cache già pronta risponde a una domanda diversa da un’esecuzione che deve costruirla; scegliere una sola delle due condizioni senza dichiararla può spostare il risultato più di una piccola differenza nella tariffa.

Infine, durata del job e durata della pipeline non sono intercambiabili. La prima contribuisce al consumo di calcolo; la seconda comprende dipendenze tra job, lavoro in parallelo e attesa prima che le risorse siano disponibili. Sommare le durate dei job paralleli è appropriato per stimare il consumo, ma sovrastima il tempo trascorso fino al risultato.

Il foglio di calcolo: dai crediti al costo per pipeline

Una riga per job rende visibile dove nasce la spesa. Le colonne essenziali sono pipeline, piattaforma, classe del runner, vCPU, memoria, durata in secondi, unità addebitate, prezzo per unità, costo del job e tempo in coda. La riga della pipeline raccoglie poi la somma dei costi e il tempo trascorso tra l’avvio e il completamento dell’ultimo job.

Per GitHub Actions: minuti fatturabili del job = arrotondamento per eccesso di durata in secondi ÷ 60; costo del job = minuti fatturabili × tariffa della classe.
Per CircleCI: costo del job = crediti consumati × prezzo per credito. Per una previsione, crediti stimati = durata prevista in minuti × crediti al minuto della classe; nel consuntivo è preferibile usare il consumo registrato.
Costo della pipeline = somma dei costi dei job. Tempo della pipeline = istante di completamento dell’ultimo job − istante di avvio, includendo le attese.

In un esempio ipotetico, due job Linux da dieci minuti ciascuno consumano venti minuti di calcolo. Se partono insieme e non incontrano code, la pipeline finisce dopo circa dieci minuti, esclusi gli altri tempi di avvio; se partono in sequenza, ne impiega circa venti. Con le tariffe marginali delle classi Linux appena considerate, il solo calcolo costa 0,12 dollari in entrambi i casi. L’esempio isola il rapporto tra parallelismo, costo e attesa: non è una misura delle prestazioni dei servizi.

Per stimare un mese, il costo medio per pipeline va moltiplicato per tutte le esecuzioni previste, comprese quelle fallite e ripetute. Le quote incluse, gli utenti attivi e le altre voci del piano entrano in una sezione separata del foglio: attribuire l’intera quota gratuita a una singola pipeline nasconderebbe il costo marginale delle esecuzioni successive.

Perché i benchmark pubblicati indicano vincitori diversi

Nel benchmark Redmine di Semaphore, dieci esecuzioni dopo la preparazione della cache hanno dato una media di 9 minuti e 44 secondi su GitHub Actions e 13 minuti e 18 secondi su CircleCI; i runner avevano entrambi due vCPU, ma rispettivamente 7 GB e 4 GB di RAM. La prova misurava un singolo job senza parallelismo. Il risultato riguarda dunque quel carico e quelle configurazioni, compresa la differenza di memoria.

Nel test CircleCI sul codice di React, che riproduceva in rapida sequenza una giornata di commit con un limite di 500 job concorrenti, CircleCI ha riportato pipeline più rapide del 40,29% alla mediana rispetto al runner GitHub da due CPU e 7 GB usando una classe da quattro CPU e 15 GB; rispetto a un runner GitHub da quattro CPU e 16 GB, il vantaggio dichiarato scendeva al 2,09%. Qui il tempo della pipeline risentiva anche dell’avvio dei job sotto carico. La percentuale più alta combina quindi differenze di risorse e comportamento delle code.

I due esperimenti rispondono a domande diverse. Redmine mostra quanto dura un job isolato con cache preparata; la riproduzione dei commit di React sollecita più pipeline contemporaneamente. Cambiano applicazione, classi di calcolo, concorrenza e metrica riassuntiva: trasferire direttamente uno di quei risultati a un’altra suite di test darebbe al numero condizioni che non sono state misurate.

Quale risultato conta nella scelta

Per una squadra con pochi avvii simultanei, la durata del job su classi di risorse comparabili può pesare più della capacità massima di concorrenza. Se le pipeline si accumulano nei momenti di punta, il tempo in coda diventa una parte concreta dell’attesa, anche quando non aumenta il consumo di calcolo della singola esecuzione. La scelta dipende dal costo mensile del proprio volume di job e dal tempo entro cui serve ricevere il risultato.

Un confronto sul proprio repository può usare la stessa revisione del codice, la stessa suite, versioni coerenti degli strumenti e una politica di cache dichiarata. Registrare sia alcune esecuzioni isolate sia un gruppo di avvii ravvicinati permette di vedere se l’eventuale vantaggio nasce dalla velocità del singolo job o dalla disponibilità di runner. Nel foglio, questa distinzione appare come differenza tra costo per pipeline e tempo fino al risultato: è il rapporto decisivo quando il prezzo nominale del minuto coincide.