Triggers

Un workflow puede dispararse de tres formas. Las tres crean una ejecución igual de completa (mismo motor, mismo seguimiento en Ejecuciones); lo único que cambia es qué la origina.

Manual

La forma más simple: desde la lista de Workflows, pulsa Ejecutar sobre el workflow que quieras correr. Queda registrado en la ejecución como trigger_type: manual y el usuario que lo disparó.

Webhook

Un trigger de tipo webhook expone una URL propia que, al recibir un POST con el token correcto, dispara una ejecución. Es útil para conectar UrraWorkflow con otro sistema (por ejemplo, un push a un repositorio a través de un webhook de GitHub/GitLab apuntando a esta URL).

La gestión de triggers (webhook y programados) todavía no tiene un panel dedicado en la interfaz: se crean llamando a la API con una sesión de administrador ya autenticada.

curl -X POST https://tu-instancia/api/workflows/<workflow_id>/triggers \
  -H "Content-Type: application/json" \
  -H "Cookie: session=<cookie-de-tu-sesion-admin>" \
  -H "X-CSRFToken: <token-csrf-de-tu-sesion>" \
  -d '{"type": "webhook"}'

La respuesta trae el token una sola vez; guárdalo, no se vuelve a mostrar:

{"ok": true, "id": "…", "token": "…", "url": "/hooks/workflow/<workflow_id>"}

Para disparar la ejecución desde el sistema externo:

curl -X POST https://tu-instancia/hooks/workflow/<workflow_id> \
  -H "X-Webhook-Token: <token>" \
  -H "Content-Type: application/json" \
  -d '{"variables": {"branch": "main"}}'

variables es opcional y queda disponible dentro del workflow como {{ variables.branch }}.

Programado (cron)

Un trigger de tipo schedule dispara la ejecución según una expresión cron estándar de 5 campos, evaluada por un hilo de fondo que revisa cada 30 segundos si algún trigger ya debería haberse disparado.

curl -X POST https://tu-instancia/api/workflows/<workflow_id>/triggers \
  -H "Content-Type: application/json" \
  -H "Cookie: session=<cookie-de-tu-sesion-admin>" \
  -H "X-CSRFToken: <token-csrf-de-tu-sesion>" \
  -d '{"type": "schedule", "cron": "0 */6 * * *"}'

Las ejecuciones programadas no reciben variables propias; usan solo las variables: declaradas en el propio workflow YAML.

El estado de "ya disparado" de un trigger programado vive en memoria, no persistido: un reinicio del panel puede, en un caso extremo, saltarse o repetir un disparo que caiga justo en ese instante. Para instalaciones de un solo panel con baja frecuencia de cron es un riesgo aceptable.

Siguiente paso: Errores comunes.