Trabajar con Nx en un monorepo no solo te da caché inteligente y velocidad en building, testing y linting. También te entrega una configuración lista de GitHub Actions que automatiza validaciones en cada push o pull request, y te permite escalar hacia despliegues, notificaciones y publicaciones de paquetes.

Por qué el caché de Nx acelera tu flujo de trabajo

La primera vez que ejecutas un comando con Nx, el proceso tarda lo que tarda. La segunda vez, la diferencia es brutal porque entra el caché.

En la demo en vivo, una construcción tomó 40 segundos la primera vez y bajó a 2 segundos al repetirla [03:15]. Ese mismo comportamiento se repite con serve, test y lint, lo que cambia por completo el ritmo de desarrollo cuando trabajas con varias apps y librerías dentro del mismo repositorio.

¿Qué es el caché de Nx? Es un mecanismo que guarda el resultado de tareas como build, test o lint y las reutiliza si el código no cambió, evitando reejecutarlas desde cero.

A esto se suma Nx Console, la extensión que centraliza la manipulación del monorepo desde el editor y reduce la fricción de recordar comandos.

Qué hace el archivo ci.yaml que genera Nx

Cuando Nx inicializa el proyecto, crea un archivo ci.yaml dentro de .github/workflows. Ese archivo define la action que GitHub ejecuta automáticamente bajo ciertas condiciones.

En la pestaña Actions del repositorio aparece con el mismo name declarado en el YAML, y cada vez que se dispara verás su historial de ejecuciones [05:40].

Cuándo se disparan los triggers de una GitHub Action

El bloque on define los disparadores. En el ejemplo del curso se configuraron tres escenarios típicos en empresas:

• Push a la branch master, donde suele correr la validación principal.
• Push a branches que coincidan con el patrón features/**, útil para validar nuevas funcionalidades.
• Push a hotfix/**, pensado para correcciones urgentes.
• Pull request, que ejecuta las validaciones antes de mergear.

Además, mencionó dos disparadores muy usados en producción: el tagging con git tag y versiones tipo 0.1.0, y la ejecución programada con cron para correr chequeos en horarios específicos [08:20].

Qué jobs ejecuta el workflow paso a paso

Una vez disparado, el workflow define permissions en modo lectura y arranca los jobs. La secuencia básica que arma Nx es:

1. Levantar una máquina con la última versión de Ubuntu.
2. Configurar Node.js versión 20.
3. Instalar dependencias con npm ci, que omite devDependencies e instala solo lo necesario para producción.
4. Ejecutar nx run-many para correr en paralelo lint, test y build sobre todos los proyectos afectados.

El uso de npm ci en vez de npm install es clave: garantiza una instalación limpia y reproducible basada en el package-lock.json.

Cómo leer los resultados de una GitHub Action que falla

Mirar el historial del repositorio cuenta una historia. Las primeras actions del curso pasaron en verde porque solo había código base. Cuando se sumaron UI Shared, el server, las apps Angular y los primeros tests, los linters y los tests empezaron a fallar [11:05].

Al agregar los tests unitarios, esa parte se estabilizó pero los linters seguían marcando rojo por constructores vacíos y malas prácticas. Una vez corregido el código, el run-many terminó con 12 tareas exitosas y 0 fallidas, muchas de ellas servidas desde el caché de Nx.

¿Para qué sirve nx run-many en CI? Ejecuta una misma tarea, como lint o test, sobre múltiples proyectos del monorepo en paralelo, y aprovecha el caché para saltar lo que no cambió.

Ese es el valor real: el pipeline te muestra en qué commit exacto se rompió algo, qué proyecto lo causó y si el problema vive en el linter, en los tests o en el build.

Qué otras automatizaciones puedes sumar a tu pipeline

El ci.yaml que genera Nx es una base. A partir de ahí, los usos populares de GitHub Actions amplían el alcance del monorepo hacia despliegue y operaciones.

• Despliegues automáticos a AWS o Google Cloud Platform cuando los permisos y credenciales están configurados.
• Build y push de imágenes con Docker para luego desplegar en Kubernetes.
• Publicación de paquetes en el NPM registry cuando desarrollas una librería propia.
• Análisis de seguridad y reportes de cobertura de tests.
• Notificaciones a Slack, Discord, email o WhatsApp cuando un job falla o se completa un despliegue.
• Despliegues en Vercel o Netlify, releases automáticos y tests end-to-end en navegadores.

Cada una de estas integraciones requiere configuración propia (secrets, tokens, permisos), pero el punto de entrada siempre es el mismo archivo YAML que ya tienes en .github/workflows.

Cómo ver una GitHub Action ejecutándose en tiempo real

El flujo para validar tu pipeline es directo y se hizo en vivo durante la clase [16:30]:

1. Hacer un cambio en el código, aunque sea un comentario.
2. Ejecutar git add . seguido de git commit -m "clase GitHub Actions parte 2".
3. Hacer git push a la branch master.
4. Abrir la pestaña Actions del repositorio y ver el job en amarillo mientras corre.
5. Entrar al detalle para seguir cada paso del workflow hasta que termine en verde.

Esa retroalimentación inmediata, sumada al caché de Nx y a la estructura monorepo con Angular en el frontend y Node.js en el backend, cierra el círculo: un solo repositorio, validaciones automáticas y la libertad de sumar despliegues cuando los necesites.

¿Qué automatización vas a configurar primero en tu monorepo? Cuéntalo en los comentarios.