Validación de cambios con Acciones de GitHub

Con el desarrollo basado en troncos implementado, cada cambio propuesto pasa por una solicitud de incorporación de cambios. Esa solicitud de incorporación de cambios también es el momento natural para ejecutar comprobaciones automatizadas. Un cambio que interrumpe el script de entrenamiento no debe alcanzar mainy un revisor no debe tener que detectar manualmente todos los errores de código.

Flujos de trabajo, desencadenadores y la puerta de calidad

Un flujo de trabajo de Acciones de GitHub es un archivo YAML almacenado en el repositorio en .github/workflows/. Define qué ejecutar, cuándo ejecutarlo y en qué secuencia. Un desencadenador (la on: clave) indica GitHub cuándo iniciarlo.

Para el flujo de trabajo de validación de Proseware, el pull_request desencadenante es adecuado para la tarea. De forma predeterminada, se ejecuta cuando una solicitud de extracción se abre, se vuelve a abrir o recibe nuevos commits. Su resultado aparece como una comprobación de estado en la solicitud de incorporación de cambios.

Tareas, runners y pasos

Un flujo de trabajo organiza el trabajo en trabajos. Cada trabajo se ejecuta en un ejecutor: una máquina virtual proporcionada por GitHub o una que administra su organización. Un job contiene una serie ordenada de pasos que extraen el repositorio, instalan herramientas y ejecutan comandos.

Para el código de entrenamiento de Proseware, un trabajo de validación podría:

1. Consulte el repositorio.
2. Instale un linter (como Flake8 para Python) y ejecútelo en los scripts de entrenamiento.
3. Ejecute pruebas unitarias (como Pytest) para comprobar que las funciones de script se comportan correctamente.

Estos pasos se ejecutan automáticamente en cada solicitud de incorporación de cambios. Nadie tiene que recordar ejecutarlos localmente.

Realización de comprobaciones necesarias

Ejecutar comprobaciones automáticamente es solo la mitad de la protección. La otra mitad consiste en hacer que esas comprobaciones sean bloqueantes. En la configuración de protección de ramas, la opción Exigir que las comprobaciones de estado se superen antes de la fusión permite especificar tareas concretas. Una solicitud de extracción no puede fusionarse hasta que los trabajos especificados se completen correctamente.

Juntos, el desarrollo basado en trunk y las comprobaciones de estado obligatorias forman una barrera de calidad: el científico de datos abre una pull request, se ejecuta el flujo de trabajo y el botón de fusionar permanece deshabilitado hasta que el código supera las comprobaciones.