El dolor que causa GitHub Actions

• Problemas de GitHub Actions

  • Recientemente se invirtió mucho tiempo en reescribir scripts de CI con GitHub Actions. Antes se usaba Earthly, pero fue descontinuado, así que se volvió a GitHub Actions.
  • El CI es complejo e incluye cola de merge, varios runners, compilaciones de Rust, imágenes de Docker, pruebas de integración y más. Cada merge de un PR consume mucho tiempo de CI.
  • Como buena práctica de software, todas las pruebas deben pasar, los errores menores deberían corregirse automáticamente y los artefactos probados deberían ser idénticos a los de la release. GitHub Actions lo hace posible, pero su configuración es compleja e inconsistente.

• Verificaciones de estado y cola de merge

  • La cola de merge de GitHub ejecuta CI después de hacer rebase del PR sobre la rama principal. Sin embargo, el CI debe ejecutarse tanto antes como después de entrar en la cola, y configurarlo es difícil.
  • La solución es usar el mismo nombre de job en ambas etapas. Así, ambas deben aprobarse.

• Problemas de seguridad

  • Recientemente se comprometió una GitHub Action popular. Como respuesta, se recomendó fijar las dependencias por hash, pero la mayoría de los usuarios no lo hace.
  • El modelo de seguridad de GitHub es complejo y difícil de entender. Se pueden configurar los permisos predeterminados de GITHUB_TOKEN, pero no está claro cómo quitar permisos.
  • Los permisos del workflow no dependen de la acción en sí, y resulta extraño elevar permisos dentro del código.

• La combinación de Docker y GitHub Actions

  • En GitHub Actions se puede ejecutar trabajo dentro de contenedores, pero surgen problemas por permisos de archivos y por cambios en la ubicación del directorio $HOME.
  • El campo de contenedor tiene muchas limitaciones, por lo que no es posible sobrescribir el entrypoint ni ejecutar solo algunos pasos dentro del contenedor.

• Desarrollo de workflows con YAML

  • Escribir lógica en YAML puede volverse complejo y es fácil cometer errores. Se usó el IDE RustRover para hacer algunas validaciones, pero hace falta una mejor verificación estática.
  • Es difícil probar localmente, así que hay que crear el mismo repositorio, hacer commits y push repetidamente hasta que el CI funcione.
  • Se mantienen los workflows pequeños y se publican artefactos para reutilizarlos en otros workflows. Sin embargo, descargar artefactos requiere un token.

• Conclusión

  • El nuevo script de CI redujo mucho el tiempo de merge, pero el proceso de configuración es complejo y el debugging es difícil. Hace falta innovación.

[GN⁺]

Opiniones de Hacker News

• Hay quienes opinan que GitLab es mejor, pero GitLab también tiene problemas de otra manera

  • Después de usar varias herramientas de CI, lo importante es escribir la mayor cantidad posible de la lógica de CI en código propio
  • Vale la pena invertir para poder ejecutar el pipeline localmente en la máquina del desarrollador
  • Hay que evitar usar YAML tanto como sea posible
  • No se debería depender de herramientas nuevas financiadas con capital de riesgo
  • Siempre que sea posible, hay que usar runners propios y operarlos on-premises

• Resulta interesante que GitHub Actions y DevOps reciban críticas tan generalizadas

  • Configurarlo y probarlo puede ser engorroso, pero una vez que funciona casi no se toca
  • Aparte de actualizar la versión de Node, casi no he modificado los workflows en 4 años
  • En lo personal, estoy satisfecho

• Usé GitLab y luego me cambié a GitHub, pero me decepcionó

  • Siento que GitHub Actions es muy inferior a GitLab
  • Si operara una empresa, elegiría GitLab

• Lo peor es tener un ciclo de retroalimentación de 30 a 60 segundos

  • Intenté replicar el entorno de GHA localmente, pero fue imposible
  • Un pequeño error termina consumiendo mucho tiempo

• No quiero que el CI modifique el código automáticamente

  • Las comprobaciones menores deberían ejecutarse con un pre-commit hook

• Me decepciona que el desarrollo de GitHub Actions parezca haberse estancado

  • Es una lástima que se haya detenido el desarrollo de Earthly y Dagger
  • Tras evaluar Depot.dev, parece que un equipo muy inteligente resolvió bien el problema

• GitHub Actions hace que se abuse de los contenedores como si fueran scripts de instalación

  • En los workflows, mucho tiempo se va en ejecutar instaladores

• Es importante elegir la herramienta adecuada

  • GitHub Actions sirve para tareas simples, pero no para tareas complejas

• Por los problemas de seguridad de GitHub Actions, hay que fijar las dependencias usando hashes

  • Usar hashes es mucho más seguro

• GitHub Actions tiene muchos problemas

  • Límite de caché de 10 GB, restricciones de concurrencia según el tipo de runner, costos altos, etc.
  • Depot.dev busca hacer GitHub Actions más rápido y resolver esos problemas
  • Acelera la construcción de imágenes Docker y optimiza los runners para que las tareas sean muy rápidas
  • GitHub Actions es muy popular, pero todavía tiene mucho margen de mejora