- Quejas sobre GitHub Actions
- El equipo está compuesto por unas 15 personas de ingeniería, y todas hacen push de código continuamente a la rama
main
- El código existe en forma de monorepo dividido en varios módulos, y se despliega varias veces al día mediante un enfoque de desarrollo basado en trunk
- Hay casos en los que GitHub Actions funciona bien, pero en cierta escala o en ciertos entornos sus límites se vuelven evidentes
Pull requests y comprobaciones obligatorias
- El monorepo está dividido en varias carpetas, y cada carpeta ejecuta de forma independiente sus pruebas, compilación y despliegue
- Se usa la función
paths de GitHub Actions para activar un pipeline solo cuando hay cambios en una carpeta específica
- Que todas las comprobaciones deban pasar antes de fusionar un pull request es un buen principio, pero al combinarlo con una estructura de monorepo surgen problemas
- Ejemplo: se configuró la comprobación
web-app1 - Unit tests como “obligatoria”, pero si no hay cambios en la carpeta web-app1, esa comprobación no se ejecuta
- Como resultado, aunque solo cambie una carpeta, las pruebas relacionadas con otras carpetas no se ejecutan y termina siendo imposible hacer el merge
- Esto podría resolverse si GitHub no lo manejara por el nombre de la comprobación obligatoria, sino con algo como “se puede fusionar si todas las comprobaciones activadas actualmente pasan”, pero es lamentable que no haya habido cambios en 3 años
- En los hilos de issues relacionados de GitHub 1, 2 también se puede ver el gran impacto de este problema
- Al final, para esquivarlo, ejecutar pipelines adicionales o mantenerlos se vuelve una situación compleja y costosa
Reutilización y YAML
- A medida que el tamaño de los pipelines crece, da la impresión de que administrarlos con GitHub Actions se vuelve cada vez más difícil
- Se terminan agregando muchos
if, y aunque se separen los workflows, aumenta la cantidad de archivos que hay que gestionar, lo que reduce la mantenibilidad
- Incluso en la reutilización, partes de invocación que deberían resolverse en una sola línea requieren varias líneas y configuración duplicada, y ya se han acumulado más de 30 archivos en la carpeta
.github
- También ocurre que en la cláusula
needs, si en un refactor no se refleja un job eliminado, puede pasar tiempo antes de detectar el error
- Como GitHub Actions no puede ejecutarse localmente, el desarrollo y las pruebas son complicados
- Existen herramientas como
act, pero en el uso real suelen tener muchas limitaciones y a menudo no cumplen con lo esperado
La indiferencia de GitHub
- El mayor problema entre los anteriores es que GitHub parece no considerar estos issues como algo muy importante
- Varias issues siguen abiertas desde hace años y no están incluidas en el roadmap público, lo que hace pensar que no hay mucha intención de mejorarlas
- Incluso problemas que se mencionaron durante mucho tiempo generaron rechazo en la comunidad cuando recientemente se cerró una gran cantidad de issues
Opciones
- Considerando estos problemas y la falta de intención de mejora por parte de GitHub, conviene ser cautelosos antes de adoptar GitHub Actions
- En el mercado hay varias opciones de CI/CD, como GitLab, Jenkins y TeamCity
- También vale la pena evaluar herramientas como Dagger, que proponen un enfoque nuevo
6 comentarios
CI/CD: GitLab es lo máximo
Yo también recuerdo que, después de usar GitLab, cuando me tocó estar en un entorno con GitHub Actions sentí que no había nada que funcionara...
Una de mis grandes quejas también es que en GitHub no se pueden agrupar y administrar los repositorios por grupos.
Creo que GitLab es realmente muy bueno para los pipelines. Todo lo que se mencionó arriba, GitLab sí lo hace.
En el caso de un monorepo, es muy conveniente configurar que, cuando cambie cierta carpeta, se ejecute esto, aquello y lo otro para las pruebas.
Creo que antes de volver a usar GitHub Actions lo voy a pensar una vez más.
Pero para esto hay que conocer la historia de GitHub Actions...
Las primeras versiones de GitHub Actions mostraban un panorama distinto al actual... Unos 6 meses antes de su apertura (si no mal recuerdo), GitHub fue adquirido por Microsoft, y creo que el desarrollo de Actions pasó a hacerse junto con el equipo de Azure DevOps en MS. En ese momento, Azure DevOps dejó de recibir nuevas funciones, y las funciones que estaban en Azure DevOps empezaron a aparecer como novedades en GitHub Actions... Fue entonces cuando se cambió a YAML y se formó el entorno actual... snif.
Después de eso, como que los desarrolladores volvieron a sus áreas y da la impresión de que ya no le han metido mano... Es una lástima... En mi empresa actual tenemos armado el CI/CD sobre la base de GitHub Actions... y como todavía no nos ha faltado nada, lo seguimos usando...
Supongo que habrá que seguirlo de cerca...
Opiniones de Hacker News
Un DSL de pipeline no debería incluir lógica real; solo debería usarse para orquestar tareas. El trabajo complejo debería convertirse en scripts que puedan ejecutarse fácilmente. Así, las mismas tareas pueden realizarse de forma simple en GitHub Actions, Jenkins, Azure DevOps, etc.
Al configurar GitHub Actions, es mejor evitar las acciones prefabricadas y usarlo solo como un ejecutor simple de shell. Si escribes scripts en Python, Ruby, Bash, etc. y los ejecutas desde GitHub Actions, es más fácil probarlos localmente y se evita sufrimiento innecesario
GitHub Actions puede ejecutar verificaciones solo cuando se cumplen ciertas condiciones. Pero al usar estas reglas, te enfrentas al problema de "pull request y verificaciones obligatorias". Cuando se usa con servicios externos, las verificaciones obligatorias deben pasar sí o sí; de lo contrario, no se puede hacer merge
Como forma de resolver el problema de "pull request y verificaciones obligatorias", se puede crear una versión "no op" de cada flujo de trabajo de verificación obligatoria para que se ejecute cuando no se cumplan las condiciones y termine con código 0. Es una solución basada en funciones estándar, pero algo complicada
Travis CI era excelente para probar CI localmente. GitHub Actions se creó para competir con GitLab CI, y GitHub estaba perdiendo participación en el mercado empresarial
Recomiendan probar Buildkite. Si ya superaste GitHub Actions, Buildkite puede ser una buena alternativa. Hay experiencia usándolo en grandes empresas tecnológicas de EE. UU., y fue la única parte realmente agradable del CI
La arquitectura de GitHub Actions puede llevar a tomar malas decisiones de seguridad. Por ejemplo, los secretos de organización o del repositorio son convenientes, pero también pueden convertirse en una vulnerabilidad. Los entornos del repositorio pueden tener secretos separados, pero hay que asegurarse de que solo los flujos de trabajo correctos puedan acceder al entorno correcto
La filosofía general de los sistemas de CI está equivocada. En vez de que el CI ejecute el código, el código debería ejecutar al CI. El CI debería ofrecer una API para que el usuario pueda proporcionarle información al sistema
Se puede usar Bazel para que la herramienta de CI construya objetivos de Bazel y, cuando sea necesario, aumentar el paralelismo mediante ejecución remota de builds. Esto es adecuado para bases de código de unas 10M+ líneas o servicios a gran escala
En GitHub se pueden definir "verificaciones obligatorias", que siempre deben estar en verde. Pero si solo se ejecutan cuando hay cambios en ciertas carpetas, entonces no se puede hacer merge cuando los cambios están en otras carpetas. Si no se ejecutan todas las pruebas, la integración pierde sentido, así que hay que hacer que las pruebas se ejecuten rápido