Flujos de trabajo
Adios Workflows conecta API, scripts, bases de datos, correo electrónico, almacenamiento de objetos y agentes de IA en una secuencia de acciones registradas. Inicia una ejecución manualmente, desde un webhook o evento, o en un intervalo recurrente. Añade una aprobación humana antes de una acción que necesite revisión.
Empieza con una receta completa: procesar un webhook, enviar un informe programado, o revisión antes de publicar. El resumen de flujos de trabajo también incluye ejemplos de S3 y scripts.
En esta página: manifiesto, desencadenantes, las diez acciones, salidas y dependencias, secretos y variables de entorno, y crear e inspeccionar.
Manifiesto de flujo de trabajo
Un manifiesto de flujo de trabajo describe desencadenantes, contexto compartido y pasos ordenados. En un repositorio dedicado exclusivamente a flujos de trabajo puedes llamar al archivo adios.yaml. En un repositorio de aplicaciones, mantén el manifiesto de ejecución de la app en la raíz del proyecto y guarda los manifiestos de flujos de trabajo en un directorio como workflows/.
workflow_id: daily-market-brief
title: Daily market brief
team_id: team-local
enabled: true
version: "1"
triggers:
- type: schedule
interval: 24h
- type: webhook
event: market.brief.requested
context:
market_api_url: https://api.example.com
symbols:
- AAPL
- MSFT
- NVDA
steps:
- step_id: fetch-prices
name: Fetch prices
kind: http
command:
method: GET
url: "{{ .context.market_api_url }}/quotes?symbols=AAPL,MSFT,NVDA"
headers:
X-API-Key: secret://MARKET_DATA_API_KEY
- step_id: select-close
name: Select close prices
kind: data-json
dependencies:
- fetch-prices
command:
from_step: fetch-prices
path: ".quotes"
- step_id: publish-brief
name: Publish brief
kind: http
dependencies:
- select-close
command:
method: POST
url: https://dashboard.example.com/api/market-briefs
body: "{{ index .steps \"select-close\" \"output\" }}"
Reemplaza los marcadores team-local por tu ID de equipo, configura los endpoints de API y crea MARKET_DATA_API_KEY en los secretos de Adios antes de desplegar este ejemplo. Su API de origen espera un X-API-Key; su destino recibe las cotizaciones seleccionadas como JSON. La programación se repite cada 24 horas. Elimina triggers para una prueba exclusivamente manual antes de habilitar la entrega recurrente.
Los desencadenantes y la programación
- Manual: omite
triggerse inicia una ejecución desde Flujos de trabajo. - Webhook: usa
type: webhooky un nombre de evento, comoorder.created. La carga útil del evento entrante está disponible como.payload. - Evento: usa
type: eventy el nombre del evento interno para que coincidan. - Intervalo: usa
type: schedulecon una duración positiva, comointerval: 1hointerval: 24h. - Cron: el planificador actual admite
@every 1h,* * * * *, y intervalos de minuto tales como*/5 * * * *. No evalúa expresiones de cron del calendario general, como0 8 * * *.
Los intervalos miden tiempo transcurrido; no están alineados con una hora del reloj. Una programación detectada por primera vez puede ejecutarse en la siguiente comprobación del planificador, y reiniciarlo restablece su seguimiento de intervalos en memoria. Aunque timezone y concurrency son campos de manifiesto admitidos, pero el planificador actual no los aplica. No dependas de concurrency: forbid para evitar ejecuciones superpuestas.
Para una hora local fija, utiliza un planificador externo que envíe un webhook. Si una repetición puede enviar informes o escrituras duplicados, implementa la deduplicación en tu aplicación o destino.
Las diez acciones compatibles
Cada paso tiene un único step_id, un kind, y opcionalmente dependencies y command. La configuración siguiente describe la ejecución en la plataforma. El ejecutor local de la CLI implementa solo un subconjunto de estas acciones.
http — Llamar a una API
Configura command.method, url, opcional headers, y body. El cuerpo de la respuesta se convierte en la salida del paso. Usa la .output para reenviar JSON como texto. Consulta el receta webhook.
- step_id: deliver
kind: http
dependencies: [order]
command:
method: POST
url: https://api.example.com/orders
headers:
X-API-Key: secret://API_TOKEN
body: "{{ .steps.order.output }}"
request-parser — Extraer campos de la solicitud
Usa command.extract para construir un objeto de selectores como .payload.order, o command.path para seleccionar un valor. Los metadatos de la solicitud, cuando los proporciona el desencadenante, están disponibles en .request. La extracción no valida un esquema.
- step_id: parse
kind: request-parser
command:
extract:
order: .payload.order
data-json — Select JSON valores
Usa command.from_step con el ID del paso de origen y path con el valor a seleccionar. path: . mantiene todo el valor; .rows[0].orders selecciona un campo de la primera fila. También puedes proporcionar command.input; sin una fuente, la acción utiliza la carga útil de ejecución. Este es un selector, no un motor de expresión jq.
bash — Ejecutar comandos de shell
Coloca el script en command: | y su entorno en el env. El worker de flujos de trabajo lo ejecuta y captura stdout como salida del paso. Usa JSON en stdout cuando otro paso necesite datos estructurados.
python — Ejecutar un script Python
Usa el mismo command y env que Bash. Lee las variables con os.environ e imprime el resultado. El ejemplo de script pasa JSON de Bash a Python y calcula un total de 97 sin credenciales externas.
sql — Consultar PostgreSQL o MySQL
Configura command.driver a postgres o mysql, dsn a un secreto de conexión y query a SQL. Las consultas de lectura devuelven columns, rows, y row_count, con un máximo de 100 filas. Las consultas que modifican datos requieren write: true y devuelve rows_affected. Consulta el receta de informe.
email — Enviar un mensaje
Configura command.provider, from, to, subject, y text o html, junto con las credenciales del proveedor. Los proveedores compatibles son smtp, sendgrid, postmark,
mailgun, brevo, mailjet, y mailchimp-transactional (también mandrill). SMTP utiliza host, port, username, y password; SendGrid utiliza api_key. Otros proveedores requieren sus propios campos de credencial y de dominio. El receta de informe muestra la configuración de SendGrid. Una acción correcta confirma el envío al proveedor, no la entrega en la bandeja de entrada.
s3 — Gestionar un objeto
Configura command.operation a put, get, head (o stat), o delete. Configura endpoint como nombre de host sin un esquema URL, region, use_ssl, access_key,
secret_key, bucket, y key. Para las subidas, proporciona body y opcionalmente content_type. Usa un bucket existente. El ejemplo de instantánea escribe JSON bajo una clave que contiene el ID de ejecución.
wait — Pausar para aprobación humana
Un wait crea una aprobación pendiente y pausa la ejecución. La aprobación permite continuar a los pasos dependientes. El rechazo hace fallar el paso y detiene la ejecución; una aprobación sin respuesta sigue en espera. No hay campos de comando para retrasos temporizados, asignación de revisores ni caducidad automática.
- step_id: approve
kind: wait
dependencies: [draft]
Haz que la acción protegida dependa de approve. Consulta el receta de aprobación para el flujo completo.
agent — Ejecutar un agente de IA configurado
Una acción de agente requiere una agent_binding_id,
agent_binding_revision_id, agent_binding_revision_digest, y workspace_id dentro command. El hash debe ser sha256: seguido de 64 caracteres hexadecimales. Usa los valores exactos de la revisión configurada de tu vinculación y luego establece input a la tarea. El flujo de trabajo espera que el agente termine antes de continuar.
La salida es el contenedor de resultados del agente en JSON, incluida la información de ejecución y los resultados; no es solo el texto del borrador. Inspecciónala antes de seleccionar un campo o reenviar el resultado completo. El receta de aprobación muestra todos los campos requeridos.
Dependencias y salidas de pasos
Enumera los ID de los pasos anteriores en dependencies y coloca esos pasos antes en el manifiesto. Si falla una dependencia, la acción posterior no se ejecuta. El entorno de ejecución actual ejecuta los pasos de forma secuencial; enumerar pasos independientes no hace que se ejecuten en paralelo.
Las plantillas usan la sintaxis de plantillas de Go. Entre los valores útiles están:
{{ .context.destination_url }}para configuración compartida.{{ .steps.report.output }}para la cadena de salida sin procesar de un paso, apta para un cuerpo JSON.{{ .steps.count.value }}para su valor analizado, apto para insertar un escalar en el texto.{{ index .steps "fetch-prices" "output" }}para un ID que contenga un guion.{{ .run.ID }}para el ID de ejecución actual.
Usa .output para pasar un objeto JSON completo como texto. Renderizar un objeto analizado mediante .value no lo codifica como JSON. Para seleccionar elementos de arrays, usa rutas como .rows[0].orders en una data-json acción.
Secretos y variables de entorno
Para acciones HTTP, SQL, de correo electrónico y S3, coloca secret://NAME directamente en el campo de comandos que necesita el valor. La referencia debe ocupar todo el campo: X-API-Key: secret://API_TOKEN resuelve, pero Authorization: "Bearer secret://API_TOKEN" se envía literalmente. Para la autenticación bearer, almacena el Bearer … en un secreto y usa Authorization: secret://API_AUTHORIZATION.
Las acciones de Bash y Python reciben variables de entorno mediante el del paso env bloque. El worker resuelve las referencias a secretos antes de iniciar el script:
steps:
- step_id: fetch
kind: python
env:
API_TOKEN: secret://API_TOKEN
API_URL: https://api.example.com/data
command: |
import os
import urllib.request
request = urllib.request.Request(
os.environ["API_URL"],
headers={"Authorization": "Bearer " + os.environ["API_TOKEN"]},
)
with urllib.request.urlopen(request, timeout=30) as response:
print(response.read().decode())
Un secrets se conserva en el modelo de datos, pero el entorno de ejecución actual no lo utiliza para rellenar los entornos de los pasos ni resolver alias. No es necesario para ninguno de los dos patrones anteriores. Las plantillas de pasos pueden leer el contexto del flujo de trabajo, la carga útil del desencadenante, los datos de la solicitud y las salidas de pasos anteriores.
Crear e inspeccionar una ejecución
Crea o aplica este manifiesto desde el editor de flujos de trabajo, el agente de IA o la CLI de flujos de trabajo. El ejecutor local de la CLI sirve para comprobaciones sencillas de desarrollo, pero admite solo un subconjunto de los tipos de pasos de la plataforma.
adios workflow deploy ./workflows/daily-market-brief.yaml
Empieza con una ejecución manual y entradas de ejemplo. Inspecciona el estado, la salida y el error de cada paso en Flujos de trabajo antes de conectar una fuente de eventos en vivo o una programación recurrente. Para las aprobaciones, prueba tanto la aprobación como el rechazo y verifica que el paso protegido siga pendiente hasta la decisión.
Usa timeout_seconds en pasos HTTP, de script, SQL o de agente cuando el valor predeterminado no sea adecuado. Los pasos HTTP, de script y SQL tienen un tiempo de espera predeterminado de 30 segundos; los pasos de agente, de 30 minutos. Un paso de espera se rige por su estado de aprobación, no por este tiempo de espera.