Un workflow, línea por línea
GitHub Actions ejecuta lo que describes en un archivo YAML cada vez que pasa algo en el repositorio. Al terminar sabrás probar en varias versiones, usar secretos sin exponerlos, pedir aprobación antes de producción y decidir qué corre en cada rama.
Workflow, evento, job y paso
En GitHub Actions, un workflow es un archivo YAML en .github/workflows/. Se dispara con eventos (on): un push, un pull_request, una hora programada (schedule) o un botón manual (workflow_dispatch). Contiene jobs, y cada job corre en una máquina nueva y limpia (el runner, elegido con runs-on). Los jobs corren en paralelo salvo que uno diga que necesita a otro con needs.
Cada job tiene pasos (steps) que se ejecutan en orden en la misma máquina: un paso run ejecuta órdenes de terminal; un paso uses reutiliza una acción publicada por otros, como actions/checkout, configurada con with. Si un paso falla, los siguientes se omiten y el job queda en rojo.
Dentro de ${{ }} se escriben expresiones que leen el contexto de la ejecución: github.ref (la rama, como refs/heads/main), github.sha (el commit), github.event_name, matrix.…, secrets.….
Toca una línea del workflow para ver qué hace.
needs, if y matrix
needs: test hace que un job espere al otro y se omita si ese falla. if: agrega una condición; la más común deja el despliegue solo para main: if: github.ref == 'refs/heads/main'. Así, las ramas y los pull requests se prueban, pero solo lo que entra a main se despliega.
Una matriz (strategy.matrix) repite un job con distintos valores, en paralelo. Sirve para probar en varias versiones de Node, de Python o en varios sistemas operativos:
test:
runs-on: ubuntu-latest
strategy:
matrix:
node: [18, 20, 22]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node }}
- run: npm ci
- run: npm test
Elige el evento, la rama y si pasan las pruebas. ¿Qué jobs se ejecutan?
Secretos y ambientes
Un pipeline que despliega necesita credenciales: un token, una contraseña del registro de imágenes, una llave SSH. Nunca van escritas en el YAML, porque el YAML está en el repositorio. Se guardan como secretos del repositorio (en la configuración de GitHub o con gh secret set NOMBRE) y el workflow los lee con ${{ secrets.NOMBRE }}. GitHub los reemplaza por *** si aparecen en los registros, y no se los entrega a pull requests que vienen de forks.
Un ambiente (environment: production) agrupa los secretos y reglas de un destino. Se le pueden exigir revisores: el job se detiene en espera hasta que una persona autorizada lo aprueba. Es la forma de implementar la entrega continua: todo automático hasta la puerta de producción, y ahí, un clic humano.
deploy:
needs: test
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
environment: production # con revisores: espera aprobación
steps:
- uses: actions/checkout@v4
- run: ./deploy.sh
env:
DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
Elige dónde vive el token y mira qué ve cualquiera con acceso al repositorio o a los registros.
Antes de leer la respuesta
Tu turno: un pipeline listo para producción
El repositorio agenda ya tiene un workflow que prueba y despliega a producción en cada push, a cualquier rama. Hay que dejarlo listo: que pruebe en Node 18, 20 y 22 (el código usa algo que Node 18 no tiene), que use el token de despliegue como secreto, que producción espere una aprobación y que las ramas de trabajo nunca desplieguen. El token que te dio el equipo es tk_prod_7c41.
Comprueba lo que entendiste
Cada respuesta incorrecta explica por qué parece correcta y en qué falla.