GitHub Actions o GitLab CI: los minutos gratis distorsionan el coste real

Para la carga privada de Linux, Windows y macOS modelada aquí, GitHub Actions tiene un menor gasto directo que GitLab CI en los escenarios que superan la cuota gratuita. La decisión puede cambiar si el código ya está en GitLab, los trabajos necesitan otros ejecutores o el equipo dispone de infraestructura propia.

Los minutos incluidos no son unidades intercambiables: cada plataforma descuenta el tiempo según sus ejecutores y aplica reglas distintas al almacenamiento. Por eso, una cuota gratuita mayor no basta para anticipar la factura de una carga mensual concreta.

Qué consume cada minuto incluido

La facturación de GitHub Actions asigna a GitHub Free 2.000 minutos mensuales para ejecutores estándar en repositorios privados y 500 MB de almacenamiento para artefactos, compartidos con GitHub Packages. Una vez agotada la cuota, el ejecutor Linux estándar de dos núcleos cuesta 0,006 dólares por minuto; Windows de dos núcleos, 0,010; y macOS estándar, 0,062. GitHub redondea el tiempo de cada trabajo al minuto completo: varios trabajos breves pueden consumir más minutos facturables que uno solo de igual duración total.

La guía de CostOps detalla otro efecto sobre la cuota de GitHub: un minuto de Windows descuenta dos minutos incluidos y uno de macOS descuenta diez, frente a uno por cada minuto de Linux. Esos multiplicadores describen el consumo de la asignación; las tarifas por minuto anteriores corresponden al uso que queda fuera de ella. Un trabajo macOS puede, por tanto, acercar la cuenta al límite mucho antes de lo que su duración sugiere.

En GitLab.com Free, la regla de minutos de cómputo concede 400 minutos al mes por espacio de nombres y multiplica la duración de cada trabajo por un factor del ejecutor. Linux x86-64 small y Windows medium tienen factor uno; Linux medium, dos; y macOS M1 medium, seis. Los ejecutores alojados de Windows y macOS figuran como beta. Los trabajos simultáneos suman consumo aunque la canalización termine antes que la suma de sus duraciones.

El tamaño de máquina impide equiparar ambas cuotas por su cifra nominal. Si una compilación pasa de Linux small a medium en GitLab y conserva la misma duración, consume el doble de minutos de cómputo. Si termina antes gracias a la mayor capacidad, el resultado dependerá del tiempo efectivamente ahorrado. La comparación exige conservar para cada trabajo su sistema operativo, tamaño de ejecutor, duración y frecuencia mensual.

La misma matriz en tres facturas mensuales

El modelo es hipotético. Cada ejecución contiene un trabajo Linux de diez minutos, uno Windows de dos y uno macOS de uno. Se supone que las duraciones se mantienen entre plataformas, que GitHub utiliza sus ejecutores estándar y que GitLab utiliza Linux small, Windows medium y macOS M1 medium. La disponibilidad beta y las imágenes de los dos últimos deben servir para la carga prevista; de lo contrario, esta factura de GitLab no representa una configuración utilizable.

Los escenarios corresponden a un repositorio privado, sin consumo de GitHub Packages ni exceso de caché. Los artefactos ocupan en promedio 0,4, 2 y 6 GiB a lo largo del mes, respectivamente. Para identificar qué trabajos de GitHub quedan fuera de la cuota en el escenario de mayor uso, el cálculo supone que se ejecutan primero todos los Linux y después los Windows y macOS. Se comparan gastos incrementales de cómputo y artefactos, sin suscripciones, impuestos ni máquinas propias.

La tarifa de GitLab ofrece minutos adicionales en paquetes de 1.000 por 10 dólares, mediante un pago único. Los minutos comprados que no se utilicen pueden pasar al mes siguiente. Por ello, las cifras de compra siguientes describen lo necesario para sostener cada mes aislado, no un coste medio de largo plazo.

• 20 ejecuciones. Producen 200 minutos Linux, 40 Windows y 20 macOS. GitHub descuenta 200 + 80 + 200 = 480 minutos de su cuota. GitLab registra 200 + 40 + 120 = 360 minutos de cómputo. Ninguna plataforma rebasa su asignación de ejecución; los artefactos medios también caben en la de GitHub. Gasto incremental calculado: cero dólares en ambas.
• 40 ejecuciones. Producen 400 minutos Linux, 80 Windows y 40 macOS. GitHub consume 400 + 160 + 400 = 960 minutos incluidos y cobra aproximadamente 0,38 dólares por almacenamiento de artefactos. GitLab consume 400 + 80 + 240 = 720 minutos de cómputo: supera su cuota en 320 y necesita comprar un paquete de 10 dólares para mantener esos trabajos en ejecutores alojados.
• 300 ejecuciones. Producen 3.000 minutos Linux, 600 Windows y 300 macOS. En GitHub equivalen a 3.000 + 1.200 + 3.000 = 7.200 minutos de cuota. Bajo el orden supuesto, los primeros 2.000 minutos Linux agotan la asignación; los 1.000 Linux restantes cuestan 6 dólares, Windows suma 6 y macOS, 18,60. Los artefactos añaden unos 1,38 dólares: el total redondeado es 31,98 dólares. GitLab registra 3.000 + 600 + 1.800 = 5.400 minutos de cómputo, supera su cuota en 5.000 y requiere cinco paquetes por 50 dólares.

El orden de ejecución solo determina a qué sistema operativo se atribuye el exceso de GitHub una vez agotada la cuota. Una distribución distinta de los trabajos puede cambiar su importe porque las tarifas de Linux, Windows y macOS no coinciden. En GitLab, los factores fijan el consumo total del modelo; la compra por paquetes hace que un exceso pequeño y otro próximo a mil minutos puedan exigir el mismo pago inicial.

El almacenamiento tiene fronteras distintas

GitHub mide el almacenamiento de artefactos por las horas durante las que permanece ocupado y lo convierte en uso mensual. Sus 500 MB incluidos equivalen aproximadamente a 0,49 GiB; con una ocupación media hipotética de 2 GiB, el exceso calculado cuesta unos 0,38 dólares al mes. Con 6 GiB medios, añade unos 1,38 dólares. Borrar un artefacto detiene el consumo futuro, pero no elimina el uso acumulado mientras estuvo guardado.

En GitLab.com Free, el límite de almacenamiento por proyecto es de 10 GiB para el repositorio Git y sus objetos LFS; los artefactos de trabajos quedan fuera de ese límite. Por eso, el modelo no añade a GitLab una compra de almacenamiento por los artefactos descritos. Un repositorio que supere el límite de Git y LFS plantea otra decisión de capacidad, separada del tiempo de CI y de la ocupación de artefactos de GitHub.

Ejecutores propios, concurrencia y repositorio

Ambas plataformas permiten usar ejecutores administrados por el equipo. Ese cambio puede reducir el consumo facturado de ejecutores alojados, pero traslada el coste a máquinas, imágenes, actualizaciones y operación. También exige capacidad suficiente cuando coinciden varios trabajos: sumar minutos permite estimar consumo, pero no indica cuántos ejecutores hacen falta para evitar esperas. Si se ejecuta código de contribuciones externas, aislar los trabajos y limitar su acceso a secretos forma parte del coste operativo.

La ubicación del código pesa en la elección. Un equipo que ya revisa cambios en GitHub obtiene allí una integración directa entre repositorio, trabajos y estado de las solicitudes de cambio; mover solo la CI obliga a mantener disparadores y resultados entre plataformas. Si el repositorio y el despliegue ya están en GitLab, una diferencia de gasto como la del modelo puede ser menor que el trabajo de separar esas operaciones. La factura útil para decidir combina la carga real por ejecutor con artefactos, concurrencia y mantenimiento, además del precio de los minutos.

Lee también:

• GitHub cayó 7 h 47 min: los reintentos multiplicaron por diez el tráfico
• PUNCH calculó una tormenta solar con solo 30 minutos de error
• GitHub migra repositorios casi sin pausa, pero solo hacia GHE.com con residencia