Los contextos en GitHub Actions son la forma oficial de acceder a información dinámica sobre la ejecución de un workflow: variables, runners, jobs, steps, secretos e inputs. Si automatizas procesos en GitHub, dominarlos te permite escribir workflows más flexibles y reutilizables.

Antes de entrar en materia, vale la pena revisar el reto anterior, porque sirve de puente para entender cómo encajan los contextos con las expresiones que ya venías usando.

Cómo se resuelve el reto de expresiones.yml

El archivo expresiones.yml define un workflow llamado Expresiones con un run name personalizado: "Estoy aprendiendo a usar expresiones". Esa etiqueta es opcional, pero cuando tu repositorio tiene varios workflows corriendo, te salva la vida para identificarlos rápido.

El trigger es workflow_dispatch y recibe dos inputs requeridos: edad (número) y nombre (string). A partir de ahí, el archivo declara dos jobs que dependen de un condicional:

• Job mayor: usa if con el operador >= y compara inputs.edad contra el literal 18. Si se cumple, corre en Ubuntu y hace echo con el nombre seguido de "es mayor de edad".
• Job menor: replica la lógica con el operador < y 18 como literal. Si la edad es menor, imprime "[nombre] es menor de edad".

La clave está en cómo las expresiones leen valores de inputs y los comparan con literales para decidir el flujo. Ese mismo patrón lo vas a reutilizar al trabajar con contextos.

Qué es un contexto en GitHub Actions y para qué sirve

Un contexto es un objeto que GitHub expone dentro del workflow para que accedas a información sobre la ejecución, los runners, los jobs y los steps. Se consultan con la sintaxis ${{ contexto.atributo }} y son la base para construir condicionales, mensajes dinámicos y lógica reutilizable.

¿Qué es un contexto en GitHub Actions? Es un objeto que te da acceso a datos en tiempo de ejecución del workflow, como el usuario que lo lanzó, la rama actual, los inputs o los secretos configurados.

Cuáles son los principales contextos de GitHub Actions

GitHub ofrece varios contextos, pero estos son los que más vas a usar:

• github: información sobre la ejecución del workflow. Por ejemplo, github.actor te devuelve el usuario que disparó el workflow, y github.ref indica la rama actual.
• env: variables de entorno definidas a nivel de workflow, job o step. Funcionan igual que las variables del sistema operativo del runner.
• vars: variables guardadas a nivel de ambiente, repositorio u organización.
• job: datos del job en ejecución. Se accede con el identificador del job, por ejemplo mayor.name o menor.name.
• steps: información de los steps en ejecución, también accedidos por su identificador.
• runner: datos del runner que está corriendo el job actual.
• secrets: nombres y valores de secretos guardados en repositorio u organización.
• inputs: entradas de triggers como workflow_dispatch, accesibles con inputs.nombre o inputs.edad.

Después de esta lista, conviene aterrizarlo con un ejemplo concreto, porque es ahí donde el operador punto cobra sentido.

Cómo usar el contexto github.ref para validar la rama

Imagina un workflow llamado contexto que se ejecuta en cada push a cualquier rama. Dentro tiene un job llamado check main con un condicional que valida la rama activa antes de seguir.

El if compara github.ref con el literal refs/heads/main. Esa cadena es la forma estándar en la que Git identifica la rama main. Si la condición se cumple, el job corre un único step que ejecuta:

yaml run: echo "Desplegando en la rama ${{ github.ref }}"

Como el condicional ya filtró por main, el output siempre será "Desplegando en la rama refs/heads/main". Aquí ves dos cosas: el contexto github se usa tanto para decidir si el job corre como para inyectar el valor dentro del echo.

¿Cómo accedo al valor de un contexto? Usas el operador punto dentro de una expresión ${{ }}. Por ejemplo, ${{ github.actor }} te da el usuario que lanzó el workflow y ${{ inputs.nombre }} te da el valor de un input del trigger.

Cuándo usar env, vars o secrets

Los tres parecen variables, pero responden a necesidades distintas:

• Usa env para valores temporales que viven durante la ejecución del workflow.
• Usa vars cuando necesites configuración persistente a nivel de repositorio u organización.
• Usa secrets para credenciales, tokens o cualquier dato sensible que no debe quedar expuesto en el log.

¿Cuál es la diferencia entre env y vars? env define variables dentro del propio archivo del workflow, mientras que vars accede a variables guardadas en la configuración de GitHub a nivel de ambiente, repositorio u organización.

Reto: crea tu propio contextos.yml

Tu turno. Crea un workflow file nuevo con el nombre contextos.yml y usa al menos uno de los contextos vistos para acceder a información relevante de un job que te resulte interesante.

Algunas ideas para inspirarte:

1. Imprimir el github.actor junto con un mensaje de bienvenida.
2. Validar la rama con github.ref antes de correr un step de despliegue.
3. Mostrar datos del runner con el contexto runner para depurar entornos.

Comparte tu solución en los comentarios y cuéntame qué contexto elegiste. En la siguiente clase vamos a ver los diferentes tipos de variables de entorno que puedes configurar en tus repositorios.