E168 - GitHub Actions para proyectos de Machine Learning

Resumen

El episodio 168 de enCoders presenta GitHub Actions como herramienta de CI/CD (integración y despliegue continuo) aplicada a proyectos de machine learning. Rodo explica los conceptos básicos (eventos, workflows, jobs, steps, acciones, runners) y los usos típicos: tests automáticos al hacer push o pull request, validación de datos antes de un merge, reportes de cobertura y despliegue a producción. Hace una demo en vivo con un repositorio de juguete (dataset de pingüinos, random forest) con workflows de Hello World, tests con pytest en una matriz de versiones de Python y validación de datos. Se muestra cómo un error de sintaxis hace fallar los tests en la interfaz de GitHub y cómo un pull request dispara los workflows. Se advierte contra usar `latest` en imágenes si se busca reproducibilidad y contra entrenar modelos pesados en GitHub Actions. Hacia el final se discute por qué estas prácticas suelen desprioritizarse frente a las urgencias del negocio y los POC que se vuelven permanentes.

Capítulos

• 00:00
  IntroSe presenta el episodio 168 sobre GitHub Actions en un proyecto básico de machine learning, con un repositorio asociado. Se define GitHub Actions como una de varias herramientas de CI/CD.
• 00:20
  Conceptos Básicos de CI/CDCI es integrar cambios de código sin romper nada, por ejemplo revisando que las métricas de un modelo sean estables. CD (delivery/deployment) tiene que ver con poner algo en producción; hay otras herramientas para lo mismo.
• 01:34
  Algunos tipos de eventosGitHub Actions puede dispararse con push, pull request o merge entre ramas. Se plantea el caso de dos personas que integran código a un repositorio maestro.
• 02:44
  Configuración y Ejecución de WorkflowsLos eventos pueden ser programados con expresiones tipo cron, manuales o por merge entre ramas, y ejecutan una función propia o una publicada por otra persona. Se ejecutan en un servidor con una cantidad limitada de minutos de construcción, por lo que un modelo que tarda días no sirve; hay que pensar en memoria y GPU.
• 05:18
  Algunas funcionalidades de GitHub ActionsUsos: tests automáticos, entrenar en horarios (Rodo prefiere Airflow para eso y los asistentes lo consideran mala práctica), validar datos (columnas, cantidad, distribución), reportes de cobertura y despliegue sin intervención manual. Para conectar con AWS/S3 se usan tokens, llaves o secretos y variables de ambiente, nunca commiteados.
• 10:28
  Cuándo CI/CD y problema con prioridades de negocioEn equipos que parten, esto se desprioriza por la urgencia de salir rápido. Es útil cuando el modelo evolucionará en el tiempo; para un modelo rápido que no cambiará en meses puede no ser necesario. Se responde una pregunta sobre pasar de DevOps a MLOps: estudiar lo que hacen los data scientists, porque el modelo se degrada y requiere reentrenamiento y monitoreo.
• 15:18
  Workflows de GitHub Actions y sus elementosSe describen workflow, eventos (push, pull_request, workflow_dispatch), jobs, steps y acciones reutilizables, más runners y runs. Se muestra un Hello World en YAML con imagen Ubuntu y se advierte no usar `latest` si se quiere reproducibilidad, sino una versión fija como Ubuntu 22.04 o 24.04. Se mencionan Bitbucket Pipelines, GitLab y Jenkins como equivalentes, y se responde que cualquier persona (también ingenieros de datos) puede usar GitHub Actions.
• 21:20
  Demostración en vivo de un Workflow básico en un proyecto de juguete de MLSe recorre el repositorio `github_actions_tutorial` (carpeta `.github/workflows`, entorno con uv, dataset de pingüinos, scripts de entrenamiento, validación y tests) trabajado en Positron desde WSL. Se explican la carga de datos local por el error "too many requests" de GitHub, el modelo random forest, `sys.exit` con 0/1, los `assert` y el debate sobre prints vs. logger, cantidad de logs y emojis. Rodo comenta que el código fue generado con asistencia de IA y tuvo que corregirlo (por ejemplo, un parámetro mal nombrado).
• 45:09
  Explorando Acciones Públicas y PrivadasEn la pestaña Actions del repositorio se ven las ejecuciones previas de Hello World. Hay que estar logueado para expandir el detalle de los pasos.
• 45:42
  Configurando y Ejecutando WorkflowsSe muestra que el workflow se dispara con push a cualquier rama y que el log imprime rama, actor y evento. El token de GitHub viene asociado a la cuenta, por lo que no hay que configurarlo.
• 47:19
  Entendiendo Runners y CachésLos runners son las máquinas que ejecutan las imágenes; existe la opción de runners self-hosted. También hay sección de cachés, y Rodo no conoce el resto de las opciones del menú.
• 47:58
  Creando y Usando PlantillasSe puede crear un workflow desde la interfaz gráfica (que a Rodo no le gusta) y hay plantillas, por ejemplo un linter de Python con Pylint. Si se crea desde la web, el archivo queda en el repositorio remoto.
• 49:00
  Pruebas con PytestEl workflow de tests corre en push a master o dev y en pull request a master, con un job `test` sobre Ubuntu.
• 49:54
  Estrategia de Matriz para Versiones de PythonUna estrategia matricial ejecuta el job en paralelo para tres versiones de Python (3.9, 3.10 y 3.11) para asegurar compatibilidad.
• 50:42
  Usando AccionesSe distingue `run` (línea de terminal) de `uses` (acción), con `actions/checkout@v4` y `setup-python`. Se muestra el marketplace de acciones y se recomienda revisar el código que corre una acción por seguridad; Rodo prefiere shell cuando es simple.
• 57:19
  Validando Datos y Manejando ErroresSe corre pytest local y luego se introduce un error de sintaxis y se hace push a dev. Falla el job de 3.11 y la interfaz marca el workflow como fallido. Se discute que el workflow falla cuando hay error o `assert` no cumplido, y que el script de validación de datos corre solo en pull request.
• 01:05:21
  Pull Requests y Automatización de WorkflowsAl crear el pull request de dev a master se ejecuta por primera vez el workflow de validar datos (344 filas, 7 columnas, condiciones cumplidas), mientras el de tests falla por el error. Se recomienda proteger la rama de producción, aceptar solo pull requests con pruebas y, si se confía en ellas, automatizar el merge y el despliegue (posiblemente con otro job). Se menciona un ejemplo con Bitbucket, S3 y Lambda, y una duda sobre credenciales de AWS en un laboratorio.
• 01:18:45
  CierreConclusiones sobre cuándo vale la pena: POC que se vuelven permanentes, presión del negocio y deuda técnica. Se anuncia que la demo con Positron Assistant queda para otro episodio, y el próximo podría ser una entrevista o intuición matemática.

Palabras clave