GitHub Actions organiza la automatización en cuatro piezas que se anidan una dentro de otra: workflow, job, step y action. Entender cómo se encapsulan te permite diseñar pipelines de CI/CD claros, reutilizables y fáciles de mantener desde tu repositorio.

Si vienes empezando con integración y despliegue continuo, aquí vas a ver cómo se conectan estos conceptos, qué papel juegan los eventos y los runners, y cómo se traduce todo a un archivo YAML real.

¿Qué es un workflow en GitHub Actions y dónde se define?

Un workflow es el contenedor más amplio: un proceso automatizado y configurable que ejecuta uno o más jobs cuando algo sucede en tu repositorio [1:20].

Se define con un archivo YAML dentro del directorio .github/workflows y un mismo repositorio puede tener varios. Lo común es separar responsabilidades: uno corre tests al hacer push, otro despliega a producción cuando los tests pasan, y otro reacciona a acciones externas.

¿Dónde viven los archivos de workflow? En la carpeta .github/workflows de tu repositorio, en formato YAML. Cada archivo describe un workflow distinto.

El YAML funciona como un superset de JSON: trabaja con llaves, valores y listas, pero con una sintaxis más legible para humanos. Un ejemplo mínimo declara name: Hola mundo y on: [push], lo que significa que el workflow se llama Hola mundo y se ejecuta cada vez que alguien haga push a cualquier rama [2:30].

¿Qué es un evento y cómo dispara un workflow?

Un event es la actividad específica que activa la ejecución del workflow [1:40]. Puede originarse dentro de GitHub o desde un sistema externo vía API REST.

Ejemplos de eventos internos comunes:

• Un push a una rama específica.
• La apertura de un pull request.
• La creación de un issue o un comentario nuevo.
• La asignación de una etiqueta.

Un evento externo, en cambio, puede ser un botón en tu página web que, al ser presionado, dispara una compilación o publica un comentario automáticamente. Esa flexibilidad es la que conecta tu repositorio con flujos de negocio reales.

¿Qué diferencia hay entre un job, un step y un runner?

Un job es un conjunto de tareas (steps) que viven dentro del workflow y se ejecutan en el mismo runner [3:40]. Un workflow puede tener varios jobs y, dentro de cada uno, los steps corren de forma secuencial: si el segundo step falla, el tercero no se ejecuta.

Como todos los steps de un job comparten el mismo servidor, también pueden compartir datos. Si un step guarda una variable o genera un archivo, el siguiente step puede usarlo sin fricción.

¿Qué es un runner y qué sistema operativo elegir?

Un runner es el servidor donde corre el job. Cada runner ejecuta solo un job a la vez, y GitHub ofrece runners gestionados con tres sistemas operativos [5:00]:

• Ubuntu: el más rápido y económico, recomendado por defecto.
• Windows: útil cuando tu app debe compilarse para ese sistema.
• macOS: necesario para builds de iOS o macOS.

También puedes registrar tus propios servidores como self-hosted runners cuando ninguno de esos tres sistemas se ajusta a tu caso. En el YAML, indicas el sistema con runs-on: ubuntu-latest dentro del job [5:50].

¿Para qué sirven runners con distintos sistemas operativos? Para compilar tu aplicación en el entorno donde se va a ejecutar. Una app multiplataforma puede tener un job por sistema operativo.

¿Qué puede contener un step?

Un step es la unidad más pequeña dentro de un job y puede ser una de dos cosas: un script de shell (un comando de terminal) o un action reutilizable [6:30].

Un ejemplo típico de job llamado Check Batch Version incluye cuatro steps: hacer checkout del repositorio con un action, configurar Node con otro action, ejecutar npm install y finalmente correr el comando que verifica la versión de la librería. Los dos primeros aprovechan trabajo automatizado por la comunidad; los dos últimos son comandos directos que tú controlas.

¿Qué es un action y por qué usarlo?

Un action es una aplicación personalizada que realiza una tarea compleja y repetitiva, condensándola en una sola línea de configuración [7:30]. Reduce código duplicado y te conecta con piezas ya probadas por otros equipos.

Piensa en hacer checkout de un repositorio sin un action: tendrías que instalar Git, configurar credenciales, clonar el repo y verificar archivos. Con uses: actions/checkout te ahorras todos esos pasos. Lo mismo pasa con configurar Node, donde un action resuelve agregar el repositorio, descargarlo, compilarlo y elegir la versión.

El GitHub Marketplace alberga más de 17 mil actions creados por GitHub, empresas y la comunidad [8:40]. Puedes usarlos tal cual o crear los tuyos para casos muy específicos.

¿Cómo se ven todos los conceptos juntos en un workflow?

Un ejemplo completo del workflow Hola mundo declara dos steps dentro del job:

1. Un step con id: ip que usa el action haythem/public-ip@v1.3 para detectar la IP pública del runner.
2. Un step que ejecuta un comando de terminal con echo "Hola mundo desde ${{ steps.ip.outputs.ipv4 }}", leyendo el dato producido por el step anterior.

Esa sintaxis con ${{ }} es la forma en que GitHub Actions referencia outputs entre steps, y la verás repetidamente en pipelines reales [9:30].

Cómo encajan workflow, job, step y action en tu día a día

La jerarquía es directa: el workflow encapsula jobs, los jobs encapsulan steps y los steps pueden contener un action. Todo corre sobre runners y se describe en YAML, un formato amigable basado en llaves, valores y listas que extiende a JSON.

Con esta base puedes diseñar pipelines separados por propósito: uno para integración continua, otro para despliegue, otro para automatizar issues o comentarios. ¿Qué workflow vas a automatizar primero en tu repositorio? Cuéntamelo en los comentarios.