Como executo lint, tests e build en cada push con GitHub Actions?

Engade un ficheiro .github/workflows/*.yml que se dispare en push, faga checkout do código, configure Node, instale dependencias e execute os teus scripts de lint/test/build como pasos. Divídeo en jobs paralelos para localizar un fallo rápido.

Por que separar en pre-deploy e post-deploy?

O pre-deploy corre as verificacións rápidas (lint, tests, build) antes de que se despregue nada. O post-deploy corre as lentas que só teñen sentido contra o sitio en vivo, como un informe de rendemento con Lighthouse, para que nunca bloqueen o despregamento.

Buscar

Integración continua con Github Actions workflow para este Proxecto

Xabier Lameiro · 9 de maio de 2023

Cada proxecto é un mundo e as súas prioridades tamén, pero todos teñen algo en común: hai que probalos e despregalos. Podes facelo a man, pero acaba sendo repetitivo e tedioso — que é xusto o que a integración e o despregamento continuos existen para quitar.

Aquí uso as Github Actions para automatizar o despregamento deste proxecto en Vercel, máis as verificacións previas: testing, linting, type-checking e xeración de documentación.

Deseño

A parte que máis se pensa é o propio pipeline: que tarefas corren e en que orde. Debuxei o fluxo en Excalidraw e fun iterando ata que unha forma me convenceu. A partir de aí é mecánico: creas un cartafol .github/workflows/ e soltas os teus ficheiros .yml. Eu teño dous, pre-deploy.yml e post-deploy.yml, e en vez de explicar a sintaxe do YAML vou explicar que fai cada job.

O pre-deploy corre catro jobs en paralelo — cancelar runs redundantes, linting, testing e docs — e só se todos pasan versiona e desprega en pre-produción. Logo probo a feature ou o bugfix a man contra esa preview. Se aguanta, despregar a produción é só un pull request de dev a master. Pero o pipeline non acaba no merge: unha vez en vivo, o post-deploy corre un pase de Lighthouse e publica un informe de rendemento páxina a páxina. Separalo así mantén as verificacións rápidas bloqueando (nada se desprega roto) e as lentas contra o sitio en vivo fóra do camiño crítico.

Aquí de forma máis gráfica:

Este é un fragmento de como se ve o workflow de pre-deploy (Node 22, npm — axusta as versións ao teu proxecto, isto é do que 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 no meu github

Cinco cousas que paga a pena facer desde o día un

Cachea a instalación. actions/setup-node con cache: npm restaura as descargas entre runs e recorta minutos de cada job. Apúntao ao teu lockfile real.
Cancela runs redundantes con concurrency:, non cunha action. Facer push tres veces seguidas non debería lanzar tres pipelines enteiros. Aquí había un paso de styfle/cancel-workflow-action, e quiteino do meu propio pipeline por dous motivos. Estaba fixado cun tag mutable, que é xusto o que a guía de hardening de GitHub che di que non fagas con actions de terceiros — un tag pódese reapuntar a código novo, que é exactamente como o compromiso de tj-actions/changed-files chegou a milleiros de repositorios en marzo de 2025. E precisaba access_token, así que en cada push entregáballe a un terceiro un PAT con permisos de escritura sobre outros cinco repositorios. A clave nativa concurrency: fai o mesmo sen token e sen código alleo.
Define permissions: explicitamente. Sen ela, o GITHUB_TOKEN leva o valor por defecto do repositorio, que é máis amplo do que un job de linting precisa. contents: read arriba do ficheiro, e subilo por job onde algo teña que escribir de verdade, é todo o cambio.
Mantén ao día os majors das actions. actions/checkout@v4 e setup-node@v4 seguen funcionando, pero declaran o runtime de Node 20, que GitHub leva tempo retirando dos runners. O major actual de ambas é @v7, e corre sobre Node 24.
Garda os segredos en secrets. O token do rexistro sae de ${{ secrets.NPM_TOKEN }}, nunca do ficheiro. Se un token chega a un .npmrc subido, rótao — o runner léeo do contorno, non do repo.

Resultados

Cada informe ten o seu propio repositorio en GitHub, e aí é onde se publica a saída de cada run:

Conclusións

Cada vez que engado un compoñente en React ou unha páxina en Next.js, unha batería de tests comproba que non rompín o traballo que xa estaba — o cal só funciona porque es ti quen ten que escribir os tests das partes delicadas e críticas. O pipeline non inventa cobertura; fai cumprir a que decidiches ter.

Podes atopar todo este código no meu repositorio de github, e se che gustou podes axudarme cunha ⭐️. Grazas!