Automatiza tu workflow con GitHub Actions
Aprende a automatizar tus tareas de desarrollo con GitHub Actions: ejemplos prácticos, consejos y trucos para optimizar tu flujo de trabajo.
Cuando hablamos de automatizar el workflow de desarrollo, GitHub Actions se ha convertido en una herramienta imprescindible. No importa si trabajas solo o en equipo, poder lanzar tests, builds o despliegues automáticamente al hacer push te ahorra horas de trabajo manual y errores tontos. Aquí te cuento cómo sacarle partido sin volverte loco en el intento.
Lo básico: estructura de un workflow
Un workflow se define en un archivo YAML dentro de .github/workflows/. Cada archivo representa una automatización que se dispara por eventos como push, pull_request o incluso un horario programado. La estructura mínima es esta:
name: CI básico
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Ejecutar tests
run: npm test
Fíjate en que usamos actions/checkout para clonar el repositorio dentro del runner. Sin ese paso, no tienes acceso a tu código. Es el primer paso en casi cualquier workflow.
Ejemplo práctico: tests y lint automáticos
Imagina que tienes un proyecto Node.js. Quieres que cada vez que alguien haga un push a la rama main, se ejecuten los tests y el linter. Así lo haría yo:
name: Test y lint
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
quality:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configurar Node
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Instalar dependencias
run: npm ci
- name: Lint
run: npm run lint
- name: Tests
run: npm test
npm ci es clave aquí: instala las dependencias exactas del package-lock.json, evitando sorpresas. Y al separar lint y tests en pasos distintos, si falla uno, sabrás exactamente cuál es el problema.
Despliegue automático con secrets
Aquí es donde GitHub Actions brilla. Puedes desplegar a un servidor por SSH o publicar en un bucket de S3 sin exponer credenciales. Los secrets se guardan en Settings > Secrets and variables > Actions de tu repositorio.
Un ejemplo de despliegue a un VPS por SSH:
name: Deploy a producción
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Copiar archivos al servidor
uses: appleboy/scp-action@v0.1.7
with:
host: ${{ secrets.SERVER_HOST }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
source: "dist/*"
target: "/var/www/miweb"
- name: Reiniciar servicio
uses: appleboy/ssh-action@v1.0.3
with:
host: ${{ secrets.SERVER_HOST }}
username: ${{ secrets.SERVER_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
cd /var/www/miweb
systemctl restart miweb.service
Nunca pongas contraseñas o claves directamente en el YAML. Si lo haces, las estarás exponiendo a cualquiera con acceso al repositorio.
Trucos y buenas prácticas
Caché de dependencias. Instalar paquetes cada vez es lento. Con actions/cache puedes guardar la carpeta node_modules y acelerar mucho tus runs:
- name: Cache de npm
uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
Filtra eventos con cuidado. No quieres que el workflow de producción se lance con un cambio de documentación. Usa paths-ignore o paths para limitar qué archivos disparan la automatización.
Reutiliza con actions compuestas. Si tienes pasos repetidos en varios workflows, créate una action propia en una carpeta .github/actions/. Es como una función reutilizable para tus pipelines.
Conclusión
GitHub Actions no es solo para proyectos grandes; incluso un blog o un script personal se benefician de automatizar tareas repetitivas. Empieza con algo pequeño: un workflow que ejecute tus tests. Luego añade el despliegue. En una tarde tienes un pipeline decente que te ahorra dolores de cabeza cada vez que haces commit. Y recuerda: los logs de cada ejecución son tus mejores aliados para depurar cuando algo falle.