Configurar un workflow file en GitHub Actions implica decidir cuándo se ejecuta, con qué condiciones y qué datos recibe. Aquí verás la solución comentada de un reto con múltiples triggers, además de los literales, operadores y funciones que dan flexibilidad a tus workflows.

Cómo se resuelve un workflow con varios triggers en GitHub Actions

La solución parte de un archivo llamado triggers.yml, nombre obligatorio para que los actions del repositorio reconozcan el reto como completado y desbloqueen el siguiente en el readme.

Dentro del archivo, el campo run-name recibe el texto estoy aprendiendo a usar diferentes triggers. Ese valor aparece en la pestaña de actions y permite distinguir ejecuciones cuando un mismo repositorio acumula varios workflows. Es opcional, pero ayuda muchísimo cuando necesitas revisar logs de una corrida específica.

¿Qué hace el campo run-name en un workflow? Define el nombre visible de cada ejecución en la consola de actions. Es opcional, pero facilita identificar qué workflow corrió cuando hay varios activos.

Qué triggers se combinaron en el archivo triggers.yml

El reto pedía al menos tres triggers. La solución usa cinco para mostrar cómo conviven distintos eventos en un mismo archivo.

• push sobre la rama master, para correr cada vez que se sube código a esa rama.
• pull_request con los tipos opened, synchronized y reopened, y filtro de paths en archivos .py usando **/*.py.
• issues con tipo labeled, que dispara el workflow cuando alguien etiqueta un issue.
• workflow_dispatch con dos inputs: lenguaje_favorito de tipo choice con Python como valor por defecto, y nombre de tipo string.
• schedule con la expresión 15 22 * * *, que ejecuta el workflow todos los días a las 10:15 PM en horario UTC.

Un detalle clave: dentro de un mismo trigger, las condiciones se suman. Si abres un pull request de un archivo .js, no corre, porque no cumple el filtro de paths. Pero entre triggers distintos basta con que uno se cumpla. Subir un .js a master activa el push, aunque no el pull request.

Cómo se estructuran los jobs cuando hay inputs y condicionales

El archivo define dos jobs. El primero, Hola mundo manual, toma los inputs del workflow_dispatch, los guarda en variables de entorno y corre un script de Python que imprime Hola, mundo, desde Python, soy Juan.

El segundo job incluye un condicional con if que solo lo ejecuta cuando el evento que lo lanzó no es un workflow_dispatch. Así, ese job solo corre con push, pull request, issues o schedule, y reutiliza el Hola mundo del reto anterior.

Qué literales y operadores admite GitHub Actions en sus expresiones

Las expresiones se escriben entre ${{ }} y aceptan varios tipos de literales que cubren la mayoría de casos cotidianos.

• Valores null para representar ausencia de valor.
• Booleanos true o false.
• Enteros positivos y negativos.
• Flotantes con punto decimal.
• Notación hexadecimal, útil para colores o IPv6.
• Notación exponencial como -2.22e-2, equivalente a multiplicar por 10 elevado a -2.
• Strings sin comillas o con comillas simples.

Del lado de los operadores, GitHub Actions replica los que usarías en JavaScript o Python:

• Paréntesis para agrupar expresiones.
• Corchetes [] para acceder a posiciones de listas o atributos de objetos.
• Punto . para acceder a atributos.
• Negación con !.
• Comparación con <, <=, >, >=, ==, !=.
• Lógicos && y || para combinar condiciones booleanas.

Esa combinación te permite escribir reglas como corre este job solo si se cumple la condición A y la B, o si se cumple la C, agrupando con paréntesis para forzar el orden de evaluación.

Qué funciones de GitHub Actions conviene conocer primero

GitHub expone funciones nativas para usar dentro de las expresiones. Estas son las más frecuentes y las que aparecen en el ejemplo de la clase.

Cómo funcionan if, contains, toJSON y fromJSON

La función if controla si un job o un step se ejecuta. En la solución del reto se usa para evitar que un job corra cuando el evento es workflow_dispatch.

contains revisa si un valor está dentro de una lista o cadena. Un caso típico: que un job solo corra cuando el label del issue sea bug, ignorando cualquier otra etiqueta.

toJSON y fromJSON convierten entre objetos del workflow y JSON. Sirven cuando necesitas imprimir un objeto completo en los logs o pasarlo como entrada a otra acción.

¿Cómo restringir un job a un label específico de un issue? Usa la función contains sobre github.event.label.name y compara con el valor que quieras, por ejemplo bug. Si no coincide, el job no se ejecuta.

Cómo se ve un workflow file con expresiones aplicadas

El segundo ejemplo de la clase define un workflow llamado expression con workflow_dispatch y dos inputs: edad de tipo integer y nombre de tipo string.

Luego declara dos jobs. El job mayor usa un if que evalúa si edad >= 18 y corre un script que imprime Juan es mayor de edad. El job menor evalúa si edad < 18 y corre un script equivalente con el texto Juan es menor de edad. Solo uno de los dos se ejecuta según el número que ingreses al lanzar el workflow.

La lógica es simple, pero muestra cómo los literales, los operadores de comparación y la función if se combinan para enrutar la ejecución según los datos que entrega el usuario.

Reto: crea tu propio archivo expresiones.yml

Es tu turno. Crea un workflow file llamado expresiones.yml que use al menos tres expresiones de las vistas. Como bonus, incorpora alguna función de las mencionadas o cualquier otra de la documentación oficial de GitHub que se ajuste a tu caso. Comparte tu solución en los comentarios y cuéntame qué funciones nuevas descubriste al explorar la documentación.