Del evento al flujo de trabajo

La campana de una cocina avisa que hay un pedido. No decide qué preparar ni si hay ingredientes. En una automatización, el evento es esa señal de inicio; el flujo define el trabajo que viene después.

Un push registra cambios en un repositorio remoto. Una solicitud de revisión propone integrarlos. Una ejecución manual permite iniciar un flujo desde la plataforma. Son momentos diferentes, y no todos deberían autorizar la misma consecuencia.

Primero define qué merece empezar

En GitHub Actions, un workflow se describe dentro de .github/workflows/. Este fragmento ilustra su sección de eventos:

on:
  pull_request:
  push:
    branches: [main]
  workflow_dispatch:

En GitHub, esa configuración solicita comprobaciones para solicitudes de revisión, pushes a main y ejecuciones manuales. El evento no garantiza que todos los trabajos se ejecuten: cada trabajo también puede tener sus condiciones.

Por ejemplo, el trabajo que prepara una entrega exige que la ejecución no sea una pull request y que la referencia sea main. Una propuesta puede necesitar pruebas sin que su código se convierta todavía en una entrega para activar.

Qué debería acompañar la señal

Para investigar una ejecución necesitas relacionarla con el cambio: repositorio, referencia, identificador y causa del inicio. Si un compañero dice «falló el pipeline», la conversación mejora cuando puede indicar qué ejecución falló y con qué código.

Un pipeline es un recorrido automatizado de tareas. Una ejecución es una instancia concreta de ese recorrido. La misma receta puede salir bien ayer y fallar hoy porque cambió el código, el entorno o una dependencia. Por eso el nombre del flujo no basta para diagnosticar.

Antes de copiar una configuración, revisa el contexto del evento y los permisos que tendrá. Nuestro ejemplo usa pull_request, lectura del repositorio y ninguna credencial de producción. No necesita ejecutar código propuesto bajo un evento con permisos ampliados.