Ir al contenido
AdiosDocumentación
Explorar la documentación

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 triggers e inicia una ejecución desde Flujos de trabajo.
  • Webhook: usa type: webhook y un nombre de evento, como order.created. La carga útil del evento entrante está disponible como .payload.
  • Evento: usa type: event y el nombre del evento interno para que coincidan.
  • Intervalo: usa type: schedule con una duración positiva, como interval: 1h o interval: 24h.
  • Cron: el planificador actual admite @every 1h, * * * * *, y intervalos de minuto tales como */5 * * * *. No evalúa expresiones de cron del calendario general, como 0 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.