GitHub Actions: tu primer workflow
Diseño Web
21

Qué es GitHub Actions

GitHub Actions es el motor de automatización integrado dentro de GitHub. Cualquier repositorio puede ejecutar tareas automáticas en respuesta a eventos: un push, una pull request abierta, una hora del día o incluso un comentario en un issue. La gran ventaja es que todo vive junto al código: no necesitas servidores externos, credenciales giradas entre servicios ni paneles adicionales.

La estructura de un workflow

Los workflows se definen en archivos YAML dentro de la carpeta .github/workflows/. Cada archivo describe un flujo independiente y GitHub los detecta automáticamente. Un workflow se compone de:

  • name: nombre legible que aparece en la pestaña Actions.
  • on: el evento o eventos que lo disparan.
  • jobs: bloques de trabajo que corren en paralelo por defecto.
  • steps: pasos secuenciales dentro de cada job.

Triggers: cuándo se ejecuta

Los triggers más usados cubren casi todos los casos reales:

  • push: cada vez que alguien empuja commits a una rama.
  • pull_request: cuando se abre o actualiza una PR.
  • schedule: con sintaxis cron, para tareas periódicas.
  • workflow_dispatch: ejecución manual con un botón en la interfaz.

Ejemplo real: correr tests PHP en cada push

Este workflow ejecuta PHPUnit cada vez que se empuja código a la rama main o se abre una pull request hacia ella:

name: Tests PHP

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  phpunit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configurar PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: mbstring, pdo_mysql
      - name: Instalar dependencias
        run: composer install --no-interaction
      - name: Ejecutar tests
        run: vendor/bin/phpunit

Cada vez que alguien abra una PR, verás un check verde o rojo directamente en la interfaz. Si el test falla, la PR se marca con una advertencia y el equipo decide si fusionar o no.

Secrets: credenciales sin exponerlas

Jamás pegues contraseñas, tokens o claves dentro del YAML. GitHub ofrece el sistema de Secrets: en la configuración del repositorio defines variables cifradas que solo son accesibles en tiempo de ejecución. Dentro del workflow las referencias así:

env:
  DB_PASS: ${{ secrets.DB_PASSWORD }}
  API_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Los logs de Actions enmascaran automáticamente los valores de los secrets, así que ni siquiera aparecen por accidente si alguien los imprime.

Consejos para no tropezar

  • Usa versiones fijas de las actions: actions/checkout@v4 en lugar de @main. Evita sorpresas cuando alguien actualice el upstream.
  • Aprovecha la caché: la action actions/cache guarda node_modules o vendor entre ejecuciones y acelera los builds drásticamente.
  • Minuta tus minutos: los planes gratuitos tienen cuota mensual de minutos. Workflows lentos consumen rápido.
  • Divide jobs: lint, tests y build en jobs separados dan feedback más granular y se ejecutan en paralelo.

Empieza con un workflow mínimo, míralo correr verde y añade pasos de a poco. En una tarde tendrás automatizado lo que antes hacías a mano cada semana.