GitHub Actions son un problema

Artículo original ↗ Discusión en Hacker News ↗

Muchos desarrolladores elogian GitHub Actions por ofrecer CI/CD gratis y cómodo en múltiples plataformas, pero cada vez lo critican más por flujos de trabajo opacos, ciclos de retroalimentación lentos, complejidad del YAML y bloqueo con el proveedor. Los comentaristas argumentan que la lógica principal de compilación y despliegue debería vivir en scripts normales que puedan ejecutarse en local o en cualquier sistema de CI, usando Actions solo como una capa delgada de orquestación. Se mencionan una variedad de alternativas y soluciones provisionales —desde herramientas como Dagger, Earthly, Garden y `act` hasta runners autoalojados y motores genéricos de workflow— todas orientadas a recuperar portabilidad, capacidad de prueba y control sobre los pipelines.

Problemas percibidos con GitHub Actions

  • Los flujos de trabajo en YAML se vuelven complejos, son difíciles de depurar y no se pueden probar fácilmente en local.
  • La fuerte dependencia de acciones de terceros hace que el comportamiento sea opaco y aumenta el bloqueo con el proveedor.
  • La terminología es confusa (actions frente a workflows), y la implementación del runner se percibe como enrevesada, con informes de comportamientos extraños y códigos de salida raros.
  • El ciclo de retroalimentación es lento: tener que hacer commits y ejecuciones remotas para iterar sobre la lógica del pipeline es algo ampliamente rechazado.
  • Algunos consideran que Actions es “lo bastante bueno”, pero inferior en claridad conceptual a sistemas más simples como GitLab CI.

Soluciones provisionales y prácticas recomendadas

  • Mantén el YAML “delgado”: úsalo principalmente para disparadores y orquestación; pon la lógica real en scripts, objetivos de Make/just, Magefiles, Bazel, etc.
  • Asegúrate de que todos los pasos de CI puedan ejecutarse en local con los mismos comandos que usa CI.
  • Prefiere scripts locales y contenedores frente a acciones reutilizables pesadas; algunos evitan todo excepto acciones básicas de configuración.
  • Usa imágenes de Docker o imágenes de devcontainer como entorno canónico tanto para ejecuciones locales como de CI.
  • Centraliza la lógica común mediante scripts compartidos o DSLs que compilan a YAML de CI; trata CI como una capa de pegamento.

Ejecución local y carencias de herramientas

  • Hay una fuerte demanda de una forma oficial de ejecutar GHA en local; los runners autoalojados actuales siguen requiriendo commits y ejecución remota.
  • act y emuladores relacionados ayudan en algunos flujos de trabajo, pero se describen como incompletos, frágiles y difíciles de depurar para pipelines complejos.
  • Las acciones de reverse shell/debug (por ejemplo, tmate) son elogiadas para resolver problemas en runners reales.

Bloqueo con el proveedor y preocupaciones de plataforma

  • El ecosistema de Actions y los runners alojados gratuitos/baratos (especialmente para Windows/macOS) se ven como un potente mecanismo de bloqueo.
  • Algunos sostienen que la monetización de CI por parte de GitHub desincentiva los runners totalmente locales y gratuitos.
  • Otros destacan el conjunto más amplio de funciones de GitHub y los efectos de red como la principal “fuerza de retención”.

Enfoques alternativos de CI/flujo de trabajo

  • Varios proyectos apuntan a soluciones agnósticas de CI o a “pipelines como código” (Dagger, Earthly, Garden, Windmill, Cirrus CLI, Cicada).
  • El DSL de Groovy de Jenkins y las bibliotecas compartidas se citan como un mejor modelo de abstracción que el YAML en bruto.
  • Los intentos de construir motores universales de workflow/CI se enfrentan a abstracciones que se filtran, variación del entorno y altos costes de migración.

Reflexiones más amplias sobre la complejidad de CI/CD

  • Muchos ven los pipelines de CI como motores de flujo de trabajo sobredimensionados que se reinventan una y otra vez.
  • Hay consenso en que los despliegues deben ser auditables, programables y no estar totalmente vinculados a un único proveedor de CI.