🐙GitHub — Actions y reglas de protección de ramas

---

¿Ya dominas los scripts PowerShell que vimos en el primer capítulo? Si ya has forjado tus scripts PowerShell para defender la calidad en Microsoft Fabric, es hora de desplegarlos en el campo de batalla de 🐙 GitHub. En este capítulo, dominaremos GitHub Actions y las Branch Protection Rules para automatizar la vigilancia de nuestro código.

Pero antes….

¡¡Gracias por el peluche, Manu!!

¿Nuestra estrategia? Convertir la rama main en una fortaleza inexpugnable🏰: solo el código que supere todas las pruebas de calidad podrá fusionarse. Para la rama dev, mantendremos un control estricto, pero con la agilidad de un ninja: los errores se reportarán con claridad, permitiendo al equipo decidir si fusionar bajo circunstancias especiales, sin frenar el desarrollo.

🔄 ¿Tu camino es Azure DevOps? Si prefieres ese dojo de entrenamiento, tenemos el pergamino sagrado para ti aquí. Pero si sigues el camino de GitHub, ¡desenvaina tu katana y continúa leyendo!

Paso 1: Configurando la GitHub Action 📄 build.yml

Nuestra Action 📄build.yml (en 📁.github/workflows/ de tu repositorio) orquestará la ejecución de los scripts PowerShell y nos mantendrá informados directamente en cada Pull Request. Al estar ubicada en un path específico GitHub Actions lo detectará automáticamente y comenzará a ejecutar el flujo de trabajo según los disparadores (`on:`) que hayas definido.

Puntos clave de esta Action:

✨Activación: Se dispara con Pull Requests a main y dev (on: pull_request: branches: ...).

🙏Permisos adecuados (**permissions:**): Concede lo necesario para leer código, comentar en PRs y actualizar “checks”.

🏋️‍♀️Organización (**Setup folders**): Prepara la carpeta scripts/testResults para los informes XML de los scripts.

💪 Control de ejecución: Scripts con id para referenciar su resultado (outcome). continue-on-error: true para asegurar que todas las validaciones se ejecuten.

📊 Informes y artefactos: actions/upload-artifact@v4 guarda los XML como artefactos para depuración. EnricoMi/publish-unit-test-result-action@v2 publica un informe de tests detallado en los “checks” del PR.

🔮 Comunicación clara (**Comment PR with results**): Un script de actions/github-script@v6 crea o actualiza un comentario en el PR con un resumen ✅/❌ de cada validación. Algo como esto:

🚫 La cláusula maestra para **main**: Si algún script falla Y el PR es a main, la Action entera se marca como fallida (core.setFailed(...)), bloqueando el merge.

Paso 2: Configurando las Reglas de Protección de Rama en GitHub

Con la Action lista, es hora de establecer las defensas.

Acceso a las 🛡️ Reglas de Protección:

1. En tu repositorio GitHub, ve a ⚙️Settings > Branches.
2. Haz clic en Add classic branch protection rule.

Rama **main**: ¡Defensa absoluta!

🗣️ Branch name pattern: main.

🤝 Require a pull request before merging: Actívalo. 🧑‍🏫 Require approvals: Actívalo (1–2 revisores).

🔥 Require status checks to pass before merging: ¡Esencial!

• Actívalo y selecciona tu job de la Action (ej: Test Results). Si este “check” falla (gracias a nuestro core.setFailed), el merge se bloquea.
• Considera activar "Require branches to be up to date before merging".

✅Create. Aquí seguramente te pida tu contraseña

Si hacemos que se ejecute nuestra Action de dev a main obtendremos algo parecido a esto:

Vemos que no nos permite hacer el merge (aparece la opción en gris clarito) a pesar de tener el ok de un revisor porque los tests han salido con errores.

Rama **dev**: 🧐 Supervisión y agilidad

➕Add rule para añadir una nueva regla.

La Action informará de errores, pero no fallará por sí misma si el PR no es a main.

🗣️ Branch name pattern: dev.

🤝 Require a pull request before merging: Actívalo (puedes ser más flexible con las aprobaciones).

🔥 Require status checks to pass before merging:

• Opción más laxa: No hacer el check FabricValidation. La decisión de fusionar recae en los revisores, basándose en el comentario y los resultados del check.

✅ Create.

Cuando creemos un Pull request y se ejecute todo , esta se verá así:

Vemos como los tests se han ejecutado, en los comentarios nos dice que hay errores, pero al tener la aprobación la opción de Merge pull request nos aparece.

Ver el vídeo en YouTube

Ver el vídeo en YouTube

🚀 ¡Tu Dojo de calidad en GitHub está operativo!

¡Misión cumplida! 🥳 Has configurado GitHub Actions y las reglas de protección de rama para crear un sistema de CI/CD robusto y adaptado a tus necesidades. Tu rama main está ahora protegida por un escudo impenetrable de calidad, mientras que dev permite un flujo de trabajo ágil pero informado.

Con cada Pull Request, tus scripts actuarán como centinelas, asegurando que solo el código más pulido y fiable avance. Has elevado tu Ki de desarrollo, ¡listo para construir soluciones de datos legendarias con la confianza de que la calidad te respalda! ¡Sigue entrenando y mejorando!