¿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.

Buscar

Integración continua con Github Actions workflow para este Proyecto

Xabier Lameiro · 9 may 2023

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:

Diagrama del pipeline de CI/CD: desde la rama dev se ejecutan en paralelo la cancelación de redundancia, la revisión de código, los tests unitarios y de extremo a extremo, y la generación de documentación con JSDoc y Storybook, publicando cada uno su informe; el versionado dispara después el despliegue al entorno de preproducción. Una pull request a la rama master dispara el despliegue a producción, tras el cual se ejecuta el test de rendimiento de Lighthouse y se publica su informe.

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]
# Cancels superseded runs. Replaces a third-party action that needed a token.
concurrency:
    group: ${{ github.workflow }}-${{ github.ref }}
    cancel-in-progress: true
# Least privilege by default; jobs that need to write raise it themselves.
permissions:
    contents: read
jobs:
    code_checking:
        name: Linting
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v7
            - uses: actions/setup-node@v7
              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 ci --legacy-peer-deps
            - name: Linter
              run: npm run lint

Workflow completo en mi github

Cinco 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 con concurrency:, no con una action. Hacer push tres veces seguidas no debería lanzar tres pipelines enteros. Aquí había un paso de styfle/cancel-workflow-action, y lo quité de mi propio pipeline por dos motivos. Estaba fijado con un tag mutable, que es justo lo que la guía de hardening de GitHub te dice que no hagas con actions de terceros — un tag se puede reapuntar a código nuevo, que es exactamente como el compromiso de tj-actions/changed-files llegó a miles de repositorios en marzo de 2025. Y necesitaba access_token, así que en cada push le entregaba a un tercero un PAT con permisos de escritura sobre otros cinco repositorios. La clave nativa concurrency: hace lo mismo sin token y sin código ajeno.
Define permissions: explícitamente. Sin ella, el GITHUB_TOKEN se lleva el valor por defecto del repositorio, que es más amplio de lo que un job de linting necesita. contents: read arriba del fichero, y subirlo por job donde algo tenga que escribir de verdad, es todo el cambio.
Mantén al día los majors de las actions. actions/checkout@v4 y setup-node@v4 siguen funcionando, pero declaran el runtime de Node 20, que GitHub lleva tiempo retirando de los runners. El major actual de ambas es @v7, y corre sobre Node 24.
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!