roadmap-retos-programacion
roadmap-retos-programacion copied to clipboard
mouredev
Feature - Automated pull request checks
Descripción de la Pull Request
GitHub Action que comprueba las Pull Requests, en base a los lineamientos establecidos. Si se desea, se podría configurar el repositorio para que el merge se realize automáticamente al finalizar exitosamente la GitHub Action de la Pull Request.
¿Cómo funciona?
Una vez abierta, editada, reabierta o sincronizada una Pull Request donde se vea afectada la carpeta Roadmap se inicia el flujo de trabajo Check pull request. Ejecutando los siguientes trabajos:
- Check title: corrobora que el número de desafío y el nombre del lenguaje de programación existan. Para luego comprobar que el formato sea
#<NÚMERO DE DESAFÍO> - <NOMBRE DEL LENGUAJE DE PROGRAMACIÓN>. - Get committed files: obtiene los archivos añadidos, modificados o eliminados de la Pull Request.
- Check committed files: verifica que los archivos obtenidos sean uno solo.
- Check committed file: verifica la extensión, el nombre y la ruta del archivo en base al número de desafío y el lenguaje de programación del título de la Pull Request.
[!NOTE]
La GitHub Action no se ejecutara si la Pull Request no afecta a la carpeta Roadmap ó si los archivos afectados son Markdowns.
[!IMPORTANT]
Si un trabajo falla, se detiene la ejecución de los siguientes y se notifica el error en las verificaciones de la Pull Request.
Archivos relevantes
- utils.mjs: Colección de funciones que obtienen la información necesaria para comprobar la Pull Request.
- check-pull-request.yml: Flujo de trabajo que comprueba la Pull Request.
- check-title/action.yml: Meta datos del trabajo que comprueba el título de la Pull Request.
- check-title/main.js: Lógica del trabajo que comprueba el título de la Pull Request.
- check-committed-file/action.yml: Meta datos del trabajo que comprueba el archivo afectado por la Pull Request.
- check-committed-file/main.js: Lógica del trabajo que comprueba el archivo afectado por la Pull Request.
- check-committed-files/action.yml: Meta datos del trabajo que comprueba los archivos añadidos, modificados o eliminados por la Pull Request.
- check-committed-files/main.js: Lógica del trabajo que comprueba los archivos añadidos, modificados o eliminados por la Pull Request.
FAQ
¿Por qué se modifico la plantilla de las Pull Requests?
Se modifico con el fin de evitar el inicio indeseado de la GitHub Action al actualizar las casillas de verificación. Además, se corrigió un error ortográfico.
¿Desde donde se obtienen los datos para corroborar la Pull Request?
La información necesaria para corroborar la Pull Request se extrae del contenido de la carpeta Roadmap del repositorio remoto. Gracias a una serie de funciones presentes en utils.mjs.
Imágenes
El trabajo Check title falla porque el título de la Pull Request es incorrecto. Reportando los errores encontrados.
El trabajo Check committed files falla porque los archivos obtenidos de la Pull Request no son uno solo. Reportando los errores encontrados.
El trabajo Check committed file falla porque la extensión, el nombre y la ruta del archivo no corresponden con el título y el autor de la Pull Request. Reportando los errores encontrados.
Se ejecutaron todos los trabajos sin errores. Por lo que la Pull Request cumple con los lineamientos establecidos para que se realize el merge automáticamente.
Hola!
Muchísimas gracias por el trabajo 🙌
A día de hoy tenemos un problema, delegar toda la revisión en el sistema exige que el usuario realice PR perfectas, y creo que estamos lejos de eso. Prefiero primar que la gente colabore a exigirles muchos cambios.
Siendo realistas, aunque se recomiendan varias cosas, lo esencial, si no me equivoco, sería esto:
- Nombre del fichero igual al del usuario (no tiene porqué coincidir en mayus/minus)
- Extensión del fichero correcta para el directorio donde se encuentra. Aquí lo que se me ocurre es que se podría generar un diccionario de extensiones|lenguaje, para así no depender del título. Y en caso de que aparezca algún nuevo lenguaje, ir dándole soporte, o simplemente no aceptar la PR y revisarla a mano.
- Un usuario puede enviar varias correcciones en la misma PR.
¿Cómo lo ves de factible?
@Roswell468 @kontroldev
Hola!
Muchísimas gracias por el trabajo 🙌
A día de hoy tenemos un problema, delegar toda la revisión en el sistema exige que el usuario realice PR perfectas, y creo que estamos lejos de eso. Prefiero primar que la gente colabore a exigirles muchos cambios.
Siendo realistas, aunque se recomiendan varias cosas, lo esencial, si no me equivoco, sería esto:
- Nombre del fichero igual al del usuario (no tiene porqué coincidir en mayus/minus)
- Extensión del fichero correcta para el directorio donde se encuentra. Aquí lo que se me ocurre es que se podría generar un diccionario de extensiones|lenguaje, para así no depender del título. Y en caso de que aparezca algún nuevo lenguaje, ir dándole soporte, o simplemente no aceptar la PR y revisarla a mano.
- Un usuario puede enviar varias correcciones en la misma PR.
¿Cómo lo ves de factible?
@Roswell468 @kontroldev
Hola! Yo agregaría a los puntos mencionados por Moure que la carpeta del lenguaje esté en minúsculas.
Buenas!
Modifique la GitHub action para que verifique solamente los aspectos esenciales de las Pull Requests, como dijo el patrón (@mouredev). Pudiendo enviar más de una corrección.
@Roswell468 también he agregado la condición que verifica que el nombre de la carpeta del lenguaje de programación sea en minúsculas. La compara con las existentes, ya que estas se encuentran en minúsculas. Además, arregle un pequeño bug en la función que obtenía las carpetas de los lenguajes de programación, ya que no captaba aquellas que en su nombre tenían un ., por ejemplo: vb.net.
En base al código todos los lenguajes existentes en el repositorio remoto deberían pasar la verificación de existencia de la GitHub Action. Si el lenguaje no existiera, un administrador debería mergear manualmente la Pull Request, solucionando el fallo para las siguientes ejecuciones de la GitHub Action.
Realizare los test para asegurarme que todo funcione correctamente. Les notificare.
Test concluidos 🧪
Luego de realizar algunos ajustes todos los Test de la GitHub Action concluyeron exitosamente. A continuación una breve descripción de estos, junto con sus respectivos enlaces:
| Test | Descripción |
|---|---|
| 01 | Corroborar que el archivo se encuentre en la carpeta del lenguaje de programación correspondiente. |
| 02 | Corroborar que el nombre del archivo equivalga al nombre del autor, sin tener en cuenta mayúsculas o minúsculas. |
| 03 | Permitir multiples correcciones, siendo cada una evaluada independientemente para corroborar que cumplen con los aspectos esenciales. |
| 04 | Comportamiento de la GitHub Action si el archivo stats.json ha sido modificado. |
Si revisan el estado de las acciones en cada Commit de los Test podrán observar las distintas respuestas de la GitHub Action.
Si se concreta el Merge recomiendo realizar un Squash de la Pull Request. Debido a que realize un Merge sin querer con una rama de mi Fork, y aunque logre revertirlo, se conservaron commits basura que ensuciarían el historial de Commits de la rama Main.
[!WARNING]
Si se quisiera que la GitHub Action realize el Push automáticamente de la Pull Request, solo si las condiciones esperadas se cumplieron, se debería agregar un nuevo Step al Job: check-committed-files. Debido a que se trata de una acción peligrosa, en caso de que se realize el Merge, recomiendo observar el comportamiento de la GitHub Action durante una semana para decidir si incorporar el Push automático o no.