4 patrones de GitHub Actions para ETL en un monorepo
Ejecutar tres sitios desde un solo monorepo crea problemas. Te enfrentas a tres trabajos ETL distintos, tres reconstrucciones de contenido y tres pipelines de despliegue. Si no los coordinas, colisionan.
Pasé seis semanas probando horarios para estabilizar esta configuración. Estos son los cuatro patrones que utilizo.
- Utilizar desfases temporales para trabajos Cron
Ejecutar todos los trabajos ETL al mismo tiempo provoca fallos. Los trabajos compiten por los límites de tasa (rate limits) de la API. Cuando HuggingFace o GitHub devuelven un error 429, la ejecución falla.
Utilizo desfases de 30 minutos para evitar esto.
- El primer trabajo comienza a las 02:00
- El segundo trabajo comienza a las 02:30
- El tercer trabajo comienza a las 03:00
Treinta minutos es tiempo suficiente para terminar una extracción pesada antes de que comience el siguiente trabajo. Esto mantiene tus logs limpios y evita colisiones de API.
- Utilizar flags de omisión para detener reconstrucciones innecesarias
Cada trabajo ETL termina con un despliegue en Vercel. Surge un problema cuando los commits de artículos también activan reconstrucciones. Sin un plan, cada actualización de artículo obliga a reconstruir los tres sitios. Esto desperdicia minutos de construcción.
Utilizo una etiqueta [skip publish-articles] en los mensajes de commit de ETL.
Añadí un paso en mi workflow para buscar esta etiqueta. Si la etiqueta existe, el workflow omite el paso de construcción y despliegue. Esto mantiene los pipelines de ETL separados de los pipelines de artículos.
- Utilizar filtros de ruta para dirigirse a sitios específicos
No querrás que la actualización de un sitio active tres despliegues. Configuro el workflow de cada sitio para que vigile únicamente su propia carpeta y la carpeta de paquetes compartidos.
Lógica de ejemplo:
- El sitio de herramientas de IA solo vigila apps/ai-tools/
- El sitio de OSS solo vigila apps/oss-alternatives/
Si cambias código en el directorio compartido, todos los sitios se reconstruirán. Acepto este compromiso porque los cambios en el código compartido son poco frecuentes.
- Añadir dispatch manual para tener control
Cron se encarga de la rutina diaria. El dispatch manual se encarga de todo lo demás. Utilizo workflow_dispatch para poder:
- Volver a ejecutar un trabajo ETL fallido
- Forzar una actualización tras añadir datos
- Realizar una prueba en seco (dry run) para probar datos sin escribirlos en la base de datos
La interfaz de usuario de GitHub muestra un menú desplegable con estas opciones. Esto evita errores tipográficos y facilita la depuración.
Resumen
Estos patrones no son complejos. Son explícitos. Mantengo un archivo markdown sencillo en mi repositorio para documentar estas reglas. Esto garantiza que no rompa el sistema cuando añada nuevos workflows.