⚡ Eventos en GitHub Actions

Hasta ahora ya hemos visto cómo crear flujos de trabajo y ejecutarlos manualmente o mediante acciones básicas como un push.

Sin embargo, una de las características más potentes de GitHub Actions son los eventos, ya que permiten automatizar tareas en respuesta a prácticamente cualquier acción que ocurra dentro de un repositorio.

De hecho, los eventos son una de las principales razones para utilizar GitHub Actions como plataforma de automatización.

🚀 ¿Qué son los eventos?

Un evento es un suceso que ocurre dentro de GitHub y que puede desencadenar automáticamente la ejecución de un workflow.

Por ejemplo:

• Cuando alguien hace un push
• Cuando se crea una Pull Request
• Cuando se abre una Issue
• Cuando se añade una etiqueta
• Cuando se publica una Release
• Cuando se deja un comentario

Cada uno de estos eventos puede utilizarse para iniciar un flujo de trabajo de forma automática.

📝 Trabajando con Issues

Uno de los ejemplos más comunes consiste en reaccionar cuando se crea o modifica una Issue.

GitHub permite especificar qué acciones concretas deben activar el workflow:

on:
  issues:
    types:
      - opened
      - reopened

Con esta configuración el flujo de trabajo se ejecutará cuando:

• Se abra una nueva Issue
• Se vuelva a abrir una Issue cerrada

Esto permite automatizar tareas de soporte, clasificación o seguimiento de incidencias.

💬 Reaccionar a comentarios

También es posible ejecutar workflows cuando se publica un comentario.

Por ejemplo:

on:
  issue_comment:
    types:
      - created

De esta forma cada nuevo comentario puede activar procesos automáticos.

Algunos casos de uso habituales son:

• Responder automáticamente
• Analizar comandos escritos por usuarios
• Etiquetar incidencias
• Ejecutar validaciones

🎯 La enorme cantidad de eventos disponibles

GitHub dispone de una gran cantidad de eventos que pueden utilizarse como disparadores.

Entre ellos encontramos:

• push
• pull_request
• issue_comment
• issues
• release
• review
• label
• workflow_dispatch

Y muchos más.

La lista es tan extensa que normalmente se consulta la documentación o se aprovecha el autocompletado del editor para descubrir todas las opciones disponibles.

🔍 Inspeccionando el evento recibido

Cuando un workflow se ejecuta, GitHub proporciona información detallada sobre el evento que lo ha lanzado.

Esa información se encuentra disponible dentro del objeto de contexto de GitHub.

Por ejemplo:

${{ github.event }}

Este contexto contiene datos muy útiles como:

• Información del repositorio
• Nombre del workflow
• Usuario que inició la acción
• Referencia de la rama
• Commit asociado
• Tipo de evento
• Datos específicos del evento recibido

Gracias a ello podemos construir automatizaciones mucho más inteligentes.

📦 El contexto GitHub

El objeto github es una de las fuentes de información más importantes dentro de GitHub Actions.

Desde él se puede acceder a:

• Datos del repositorio
• Información del workflow
• Referencias de ramas
• Variables de entorno
• Eventos recibidos
• Tokens de autenticación

Por esta razón es habitual utilizar expresiones como:

${{ github.repository }}
${{ github.ref }}
${{ github.event }}

para obtener información dinámica durante la ejecución.

⚠️ Cuidado con los tokens

Dentro del contexto de GitHub también existen credenciales que permiten interactuar con la plataforma.

Por ejemplo:

${{ github.token }}

Estas credenciales son extremadamente útiles para automatizar tareas, pero también deben manejarse con cuidado.

Nunca deben exponerse en logs públicos ni mostrarse innecesariamente durante la ejecución del workflow.

🧪 Probando el workflow

Una forma sencilla de comprobar que el evento funciona correctamente es:

1. Crear una nueva Issue.
2. Ir a la pestaña Actions.
3. Verificar que se ha lanzado una ejecución.
4. Inspeccionar los pasos ejecutados.

Cuando GitHub detecta la apertura de la Issue, ejecutará automáticamente el workflow asociado.

⏱️ Tiempo de ejecución

Al crear una nueva Issue se puede observar que:

• La ejecución puede tardar unos segundos en comenzar.
• GitHub debe poner en marcha el runner.
• Una vez iniciado, el workflow suele ejecutarse rápidamente.

Es importante distinguir entre:

• Tiempo de espera para arrancar la ejecución.
• Tiempo real consumido por el workflow.

Normalmente GitHub factura únicamente el tiempo efectivo de ejecución.

🤖 Automatizando respuestas

Una de las aplicaciones más interesantes de los eventos es responder automáticamente a las Issues.

El flujo general sería:

1. Se abre una Issue.
2. GitHub lanza el workflow.
3. El workflow obtiene información de la Issue.
4. Se publica una respuesta automática.

Este patrón permite crear asistentes, bots o sistemas de soporte completamente automatizados.

📌 Ideas clave de esta clase

Quédate con estos conceptos:

• Los eventos son el mecanismo principal para automatizar GitHub Actions.
• Un workflow puede reaccionar a acciones realizadas dentro del repositorio.
• Issues y comentarios son eventos muy utilizados.
• GitHub proporciona un objeto de contexto con información detallada del evento.
• El contexto github contiene datos del repositorio, usuario y ejecución.
• Los tokens deben manejarse con precaución.
• Es posible construir automatizaciones que respondan automáticamente a las Issues.
• GitHub Actions permite reaccionar a una enorme variedad de eventos.

🚀 Lo siguiente: crear automatizaciones reales

Ahora que ya sabes cómo funcionan los eventos, el siguiente paso consiste en utilizar toda la información disponible dentro del contexto de GitHub para construir automatizaciones más avanzadas.

A partir de aquí podrás responder automáticamente a Issues, procesar comentarios y crear flujos de trabajo mucho más inteligentes.

---

💡 Tip: Antes de desarrollar automatizaciones complejas, inspecciona siempre el contenido de github.event. Conocer exactamente qué información recibe tu workflow te permitirá aprovechar al máximo las capacidades de GitHub Actions.