Automatizaciones

​

Conceptos básicos

​

Tipos de acciones

​

Fuentes de trigger

​

Crear una automatización

​

Desde la página de automatizaciones

1. Ve a automatización en la barra lateral
2. Haz clic en crear automatización y elige Create para abrir un editor en blanco (si aún no tienes automatizaciones, haz clic en Create manually en la página de inicio). El mismo menú también ofrece plantilla (abre la galería de plantillas) y Generate with Devin (inicia una sesión que crea la automatización contigo)
3. Configura el disparador, las Conditions y la Action
4. Haz clic en crear automatización

​

A partir de una plantilla

1. Ve a Automatizaciones en la barra lateral
2. Haz clic en Crear automatización > Plantilla (si aún no tienes automatizaciones, haz clic en Crear a partir de una plantilla en la página de inicio), o ve directamente a /automations/templates
3. Explora la galería de plantillas: cada plantilla es una automatización preconfigurada para un flujo de trabajo habitual
4. Haz clic en una plantilla para precargar el editor con su disparador, acción y límites sugeridos
5. Personaliza la configuración (p. ej., selecciona tu canal de Slack o repositorio) y haz clic en Crear automatización

​

Cómo usar el lenguaje natural

​

Configuración de disparadores

​

Disparadores de Slack

• Mensaje de Slack: Se activa cuando hay mensajes nuevos. De forma predeterminada se agrega una condición de canal; puedes eliminarla para que coincida con mensajes de todos los canales, pero en ese caso cada grupo de condiciones necesita al menos otro filtro (por ejemplo, el texto del mensaje o el tipo de remitente; Include thread replies por sí solo no es suficiente).
• Mención de grupo de usuarios: Se activa cuando se menciona a un grupo de usuarios de Slack (por ejemplo, @oncall). Selecciona el grupo o introduce su ID de Slack (empieza por S) y, si quieres, limítalo a canales específicos.
• Reacción de Slack: Se activa cuando se agrega a un mensaje una reacción con un emoji específico (p. ej., 🚨 para incidentes). Puedes filtrar por el nombre de la reacción y por el canal.

​

Disparadores de GitHub

• Incidencia: Se activa con eventos de incidencias (apertura, cierre, reapertura, edición, etiquetado).
• Comentario en incidencia: Se activa cuando se publica un comentario en una incidencia de GitHub. Suele usarse con una condición starts_with "/devin" para que los usuarios puedan escribir /devin en cualquier incidencia y activar Devin.
• Pull request: Se activa con eventos de PR (apertura, sincronización, etc.).
• Revisión de pull request: Se activa cuando se envía una revisión sobre una PR.
• Comentario de revisión de pull request: Se activa con comentarios de revisión individuales.
• ejecución de check (CI): Se activa cuando se completa una comprobación de CI. Filtra por conclusion = failure para corregir automáticamente compilaciones fallidas.
• Push: Se activa al hacer push a una rama.

​

Disparadores de GitLab

• Solicitud de fusión: se activa con acciones en la MR (abierta, cerrada, fusionada, reabierta, aprobada, actualizada).
• Comentario de MR: se activa cuando se publica un comentario (note) en una solicitud de fusión, incluidos los threads de review del diff.
• Incidencia: se activa con acciones en la incidencia (abierto, cerrado, reabierto, actualizado).
• Comentario en issue: se activa cuando se publica un comentario en una incidencia.
• Push: se activa con los pushes a una rama.
• Proceso: se activa cuando un proceso alcanza un status determinado; filtra por status (p. ej. failed) para aplicar corrección automática a los procesos que fallan.

​

Disparadores de Linear

• Incidencia creada: Se activa cuando se crea una nueva incidencia en el equipo seleccionado.
• Etiqueta agregada: Se activa cuando se aplica una etiqueta a una incidencia (p. ej. bug, devin).
• Estado cambiado: Se activa cuando cambia el estado de una incidencia (p. ej. cuando se mueve a “In Progress”).
• Prioridad cambiada: Se activa cuando cambia la prioridad de una incidencia.
• Asignada: Se activa cuando se asigna una incidencia a alguien.
• Incidencia movida: Se activa cuando una incidencia se mueve a otro equipo: el filtro de equipo del disparador coincide con el equipo de destino.

​

Disparadores de Jira

• Incidencia creada: se activa cuando se crea una nueva incidencia.
• Incidencia actualizada: se activa cuando cambian los campos de una incidencia.
• Etiqueta agregada: se activa cuando se aplica una etiqueta a una incidencia.
• Estado cambiado: se activa cuando cambia el status de una incidencia.
• Asignada: se activa cuando se asigna una incidencia a alguien.
• Comentario creado o editado: se activa cuando se agrega o se edita un comentario en una incidencia.

​

Disparadores de programación

• Recurrente: Configura la frecuencia (cada hora, cada día o cada semana) y la hora. Internamente, las programaciones usan el formato RRULE de iCalendar. Elige Programación personalizada para crear una recurrencia personalizada (repetir cada N minutos/horas/días/semanas/meses) o introducir directamente una cadena RRULE (p. ej. FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0) para cadencias más complejas.
• Ejecutar una vez: Se activa una sola vez en una fecha y hora futuras concretas, y luego se desactiva automáticamente. Es útil para tareas puntuales con retraso; p. ej., “despierta a Devin dentro de 12 horas para ejecutar una tarea”. Elige la fecha y la hora (de forma predeterminada, una hora a partir de ahora); debe ser en el futuro.

​

Disparadores de webhook

1. Crea una automatización con un disparador de Webhook
2. Copia la URL del webhook y el secreto que se muestran en la configuración del disparador
3. Configura tu sistema externo (PagerDuty, Datadog, Sentry o cualquier herramienta personalizada) para que envíe solicitudes HTTP POST a esta URL
4. Opcionalmente, agrega un filtro de carga útil: un patrón regex con el que debe coincidir el cuerpo de la solicitud para que se active la automatización

• Encabezado X-Webhook-Secret: <secret>
• Encabezado Authorization: Bearer <secret>
• Parámetro de consulta ?secret=<secret>

​

Secreto del webhook

curl -X POST '<webhook-url>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Secret: <secret>' \
  -d '{"test": true}'

​

Comprobaciones previas

​

Configurar y probar una comprobación Preflight

1. Crea una automatización o edita una existente, y configura sus triggers y condiciones.
2. Haz clic en Add a step before the agent runs, debajo de la sección del trigger. Se abrirá la card Before the agent runs.
3. Haz clic en Edit script, elige Python, Node (JavaScript) o Bash en el selector de runtime y edita el script inicial.
4. Si es necesario, usa Select secrets en el editor de scripts para adjuntar secretos de la organización. Solo los secretos seleccionados se inyectan como variables de entorno. Para guardar o probar un script con secretos adjuntos, necesitas permiso para gestionar los secretos de la organización.
5. Define Timeout (seconds) en la card: el valor predeterminado es de 60 segundos y el rango permitido va de 1 a 300 segundos. De forma predeterminada, el script usa el Minimal environment; si hay imágenes de la máquina disponibles, el selector Environment también te permite elegir una instantánea de la organización con tus dependencias.
6. En el editor de scripts, elige un evento en Test against y haz clic en Run. Puedes probar el script sin guardar con una muestra de un trigger configurado o con un evento reciente de una automatización existente. Revisa el resultado, el registro y, en el caso de los elementos emitidos, la vista previa de cuántos se ejecutarían, cuántos serían duplicados y cuántos se aplazarían.
7. Haz clic en Save script para aplicar los cambios del editor y, después, en Create automation, o guarda la automatización para conservar la configuración.

​

Entrada y salida del script

import json
import os

with open(os.environ["EVENT_FILE"]) as f:
    event = json.load(f)

text = event.get("payload", {}).get("text", "")
should_run = "urgent" in text.lower()

with open(os.environ["OUTPUT_FILE"], "w") as f:
    json.dump({"run": should_run, "reason": "Urgency filter"}, f)

​

Elementos, estado y límites

• Prevención de duplicados: El id de un elemento identifica una unidad de trabajo dentro de esta automatización, no solo una entidad. {"id": "INC-1"} se procesa una sola vez; agrega un version, como la marca de tiempo de la última actualización en el sistema de origen, para procesar una nueva ocurrencia de ese incidente. Sin un id, Preflight identifica el elemento mediante un hash de su contenido, por lo que modificar el contenido puede provocar otra ejecución.
• Límite de elementos por ejecución: De forma predeterminada, se despachan como máximo 10 elementos nuevos por ejecución; el límite máximo del sistema es 50. Los elementos que superan el límite no se procesan ni se programan automáticamente, así que la siguiente ejecución de tu script debe volver a emitirlos. No avances un cursor más allá del trabajo pendiente solo porque haya aparecido en tu salida.
• Resultados anteriores: Usa LAST_RUN_FILE para distinguir el trabajo en curso, completado, fallido u omitido. Cuando la ejecución de un elemento falla, este se libera, de modo que una ejecución posterior del script puede volver a emitirlo.
• Estado persistente: Las ejecuciones en vivo del script de una automatización se realizan de una en una. Si un script falla, no avanza el estado guardado ni marca elementos como procesados. Clear state borra tanto el estado JSON guardado como el historial de elementos ya procesados; tras este restablecimiento, los elementos procesados anteriormente pueden volver a ejecutarse.
• Límites de tamaño: El código fuente del script y su salida están limitados a 256 KiB cada uno, el estado guardado a 64 KiB y los registros capturados a 1 MiB.
• Fallos: Un código de salida distinto de cero, un tiempo de espera agotado, una salida o un estado no válidos, o un fallo de infraestructura detienen ese evento antes de que se ejecuten sus acciones. El script no se reintenta automáticamente para ese evento; un trigger posterior puede volver a ejecutarlo.
• Acceso a la red: La VM del script se rige por las restricciones de red de la automatización y por el perfil de seguridad aplicable. Por ejemplo, para sondear un servicio de alertas externo, su host debe estar permitido. Adjuntar un secreto no otorga acceso a la red.

​

Configurar acciones

​

Iniciar una sesión

• Prompt: Las instrucciones que sigue Devin. Redáctalo como lo harías con un prompt normal de Devin.
• Playbook (opcional): Usa @playbook-name en tu prompt para incluir un playbook con instrucciones adicionales.
• Tags (opcional): Agrega etiquetas a las sesiones creadas por esta automatización para facilitar el filtrado.

​

Enviar un mensaje a una sesión

​

Triaje de Devin (monitor)

​

Notificación por correo electrónico

• Siempre — en cada invocación
• En caso de error — solo cuando la sesión falla o se produce un error
• En caso de éxito — solo cuando la sesión se completa correctamente

​

Límites y salvaguardas

​

Límite de ACU

​

Límite de invocaciones

​

Puesta en cola

• Concurrent runs: el número máximo de ejecuciones simultáneas de esta automatización. Los eventos adicionales esperan en la cola. Una ejecución deja de contar para el límite en cuanto su sesión termina y queda a la espera de nuevas instrucciones.
• Queue depth: el número máximo de eventos que pueden esperar en la cola. Los eventos que llegan cuando la cola está llena se descartan.

​

Política de red

​

Integraciones MCP

​

Acceso a las herramientas de Slack

​

Actividad y monitorización

• Invocaciones recientes con fecha y hora
• Si cada invocación se completó correctamente o se omitió
• Enlaces a las sesiones de Devin que se crearon
• Mensajes de error de las invocaciones fallidas

​

Activar y desactivar

​

Plantillas