Si trabajas con automatización en GitHub, conocer los triggers de GitHub Actions te permite decidir cuándo se ejecuta cada workflow. Aquí descubrirás los seis eventos más usados, cómo configurarlos en tu archivo YAML y qué parámetros aceptan para que tus pipelines respondan exactamente cuando los necesitas.

Los triggers viven bajo la etiqueta on dentro del archivo de workflow, y cada uno admite atributos para filtrar ramas, rutas, tipos de acción o incluso entradas manuales. Vamos a verlos uno por uno con ejemplos del flujo real que usarías en tu repositorio.

¿Qué es un trigger en GitHub Actions y cuáles son los más comunes?

Un trigger es el evento que dispara la ejecución de un workflow. GitHub ofrece una lista extensa, pero seis concentran la mayoría de los casos reales [1:00]:

• push: cuando subes nuevos commits.
• pull_request: al abrir, cerrar o actualizar un PR.
• issues: al crear, etiquetar o cerrar un issue.
• issue_comment: al comentar un issue o un pull request.
• workflow_dispatch: ejecución manual desde la interfaz.
• schedule: ejecución programada por cron.

¿Qué hace la etiqueta on en un workflow? Es la sección donde declaras los eventos que activan tu workflow. Puedes incluir uno o varios triggers y filtrarlos con atributos como branches, paths o types.

¿Cómo configurar el trigger push con branches y paths?

El evento push se ejecuta cada vez que envías commits a una rama. Lo interesante está en sus filtros [3:00].

Filtrar por ramas con wildcards

Dentro de branches puedes listar ramas exactas o usar el asterisco como wildcard. Por ejemplo, releases/* captura cualquier rama que empiece por releases/ seguida de cero o más caracteres. Así, main y todas las ramas de release disparan el workflow.

Filtrar por archivos modificados

El atributo paths define sobre qué archivos se activa. Una expresión como **.js toma cualquier archivo JavaScript en cualquier subdirectorio, gracias a los dos asteriscos que admiten incluso separadores /.

yaml on: push: branches: - main - 'releases/*' paths: - '**.js'

¿Cómo usar pull_request, issues e issue_comment con types?

Estos tres triggers comparten el atributo types, que filtra subacciones específicas dentro del evento [4:30].

Pull request con acciones específicas

Un pull request admite acciones como opened, closed, synchronized o labeled. Por defecto reacciona a cualquiera, pero puedes restringirlo:

yaml on: pull_request: types: [opened, labeled] branches: - main

Issues y sus estados

Para issues aplica la misma lógica con tipos como opened, edited y closed. Útil para automatizar etiquetas, notificaciones o cierres en cascada.

Issue comment para PR e issues

Aunque el nombre diga issue_comment, este evento también reacciona a comentarios en pull requests. Si quieres limitarlo solo a PRs, usa una expresión if dentro del job que valide github.event.issue.pull_request [7:30].

yaml on: issue_comment: types: [created, deleted]

jobs: pr_commented: name: PR comment if: ${{ github.event.issue.pull_request }} runs-on: ubuntu-latest

¿Cómo lanzar un workflow manual con workflow_dispatch?

El trigger workflow_dispatch permite ejecutar un workflow a demanda desde la interfaz de GitHub, con inputs personalizables [9:00].

Cada input admite:

• description: texto que ve el usuario.
• required: booleano que obliga o no a llenar el campo.
• default: valor predeterminado si se deja vacío.
• type: puede ser string, boolean, choice o environment.

¿Cuándo conviene usar workflow_dispatch? Cuando necesitas correr un proceso bajo demanda con parámetros variables, como lanzar despliegues, alertas o tareas de mantenimiento desde la web sin tocar el código.

Un ejemplo típico es una alerta con niveles bajo, medio y alto mediante un input tipo choice, combinado con un tag booleano y un environment de tipo string para que el usuario describa el objetivo.

yaml on: workflow_dispatch: inputs: alert: description: 'Nivel de alerta' required: true default: 'medio' type: choice options: - bajo - medio - alto tag: description: 'Opcional' required: false type: boolean environment: description: 'Objetivo de la alerta' required: true type: string

¿Cómo programar workflows con schedule y sintaxis cron?

El evento schedule ejecuta tareas según un cronograma usando sintaxis cron de cinco campos [12:30]:

1. Minuto: 0 a 59 o * para cualquiera.
2. Hora: 0 a 23.
3. Día del mes: 1 a 31.
4. Mes: 1 a 12, o abreviaturas en inglés como Jan o Dec.
5. Día de la semana: 0 (domingo) a 6 (sábado), o abreviaturas como Sun o Sat.

Puedes usar comas para listar varios valores en un mismo campo. Por ejemplo, 30 5,17 * * * ejecuta el workflow todos los días a las 5:30 a.m. y 5:30 p.m.

yaml on: schedule: - cron: '30 5,17 * * *'

¿Qué significan los asteriscos en cron? Indican "cualquier valor" para ese campo. Si los cinco campos fueran asteriscos, el workflow correría cada minuto.

¿Qué reto puedes practicar con estos triggers?

Para fijar lo aprendido, crea un archivo llamado triggers.yml en tu repositorio clonado y combina al menos tres de los triggers vistos. Puedes mezclar un push con filtros de rama, un workflow_dispatch con inputs y un schedule semanal, o explorar otros triggers de la documentación oficial.

Comparte tu solución en los comentarios y compárala con la de tus compañeros antes de pasar al uso de expresiones.