¿Cómo ejecuto lint, tests y build en cada push con GitHub Actions?

Añade un fichero .github/workflows/*.yml que se dispare en push, haga checkout del código, configure Node, instale dependencias y ejecute tus scripts de lint/test/build como pasos. Divídelo en jobs paralelos para localizar un fallo rápido.

¿Por qué separar en pre-deploy y post-deploy?

El pre-deploy corre las verificaciones rápidas (lint, tests, build) antes de que se despliegue nada. El post-deploy corre las lentas que solo tienen sentido contra el sitio en vivo, como un informe de rendimiento con Lighthouse, para que nunca bloqueen el despliegue.

Xabier Lameiro · 2023-05-09

Integración continua con Github Actions workflow para este Proyecto

Cada proyecto es un mundo y sus prioridades también, pero todos tienen algo en común: hay que probarlos y desplegarlos. Puedes hacerlo a mano, pero acaba siendo repetitivo y tedioso — que es justo lo que la integración y el despliegue continuos existen para quitar.

Aquí uso las Github Actions para automatizar el despliegue de este proyecto en Vercel, más las verificaciones previas: testing, linting, type-checking y generación de documentación.

Diseño

La parte que más se piensa es el propio pipeline: qué tareas corren y en qué orden. Dibujé el flujo en Excalidraw y fui iterando hasta que una forma me convenció. A partir de ahí es mecánico: creas una carpeta .github/workflows/ y sueltas tus ficheros .yml. Yo tengo dos, pre-deploy.yml y post-deploy.yml, y en vez de explicar la sintaxis del YAML voy a explicar qué hace cada job.

El pre-deploy corre cuatro jobs en paralelo — cancelar runs redundantes, linting, testing y docs — y solo si todos pasan versiona y despliega en pre-producción. Luego pruebo la feature o el bugfix a mano contra esa preview. Si aguanta, desplegar a producción es solo un pull request de dev a master. Pero el pipeline no acaba en el merge: una vez en vivo, el post-deploy corre un pase de Lighthouse y publica un informe de rendimiento página a página. Separarlo así mantiene las verificaciones rápidas bloqueando (nada se despliega roto) y las lentas contra el sitio en vivo fuera del camino crítico.

Aquí de forma más gráfica:

Este es un fragmento de cómo se ve el workflow de pre-deploy (Node 22, npm — ajusta las versiones a tu proyecto, esto es de lo que se queda desactualizado):

pre-deploy.yml

name: Workflow Pre-Deploy
on:
    push:
        branches: [dev]
jobs:
    cancel_redundancy:
        name: Cancel Redundant Workflow Runs
        runs-on: ubuntu-latest
        steps:
            - name: Cancel previous redundant workflow runs
              uses: styfle/cancel-workflow-action@0.12.1
              with:
                  access_token: ${{ secrets.TOKEN_GITHUB }}
    code_checking:
        name: Linting
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v4
            - uses: actions/setup-node@v4
              with:
                  node-version: 22
                  cache: npm
            - name: Install dependencies
              env:
                  NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
              run: |
                  echo "//npm.pkg.github.com/:_authToken=${NPM_TOKEN}" >> ~/.npmrc
                  echo "@xabierlameiro:registry=https://npm.pkg.github.com/" >> ~/.npmrc
                  npm install --legacy-peer-deps
            - name: Linter
              run: npm run lint

Workflow completo en mi github

Tres cosas que merece la pena hacer desde el día uno

Cachea la instalación. actions/setup-node con cache: npm restaura las descargas entre runs y recorta minutos de cada job. Apúntalo a tu lockfile real.
Cancela runs redundantes. Hacer push tres veces seguidas no debería lanzar tres pipelines enteros. El paso de cancelación de arriba (o la clave concurrency: nativa) mata los runs superados.
Guarda los secretos en secrets. El token del registro sale de ${{ secrets.NPM_TOKEN }}, nunca del fichero. Si un token llega a un .npmrc subido, rótalo — el runner lo lee del entorno, no del repo.

Resultados

Cada informe tiene su propio repositorio en GitHub, y ahí es donde se publica la salida de cada run:

Conclusiones

Cada vez que añado un componente en React o una página en Next.js, una batería de tests comprueba que no he roto el trabajo que ya estaba — lo cual solo funciona porque eres tú quien tiene que escribir los tests de las partes delicadas y críticas. El pipeline no inventa cobertura; hace cumplir la que decidiste tener.

Puedes encontrar todo este código en mi repositorio de github, y si te ha gustado puedes ayudarme con una ⭐️. ¡Gracias!