Automações

​

Conceitos principais

​

Tipos de Ação

​

Fontes de acionamento

​

Criar uma automação

​

Na página de automações

1. Acesse automação na barra lateral
2. Clique em Criar automação e escolha Create para abrir um editor em branco (se você ainda não tiver nenhuma automação, clique em Create manually na página inicial). O mesmo menu também oferece Template (abre a galeria de templates) e Generate with Devin (inicia uma sessão que cria a automação junto com você)
3. Configure o gatilho, as condições e a GitHub Action
4. Clique em Criar automação

​

A partir de um template

1. Navegue até automação na barra lateral
2. Clique em Criar automação > Template (se você ainda não tiver nenhuma automação, clique em Criar a partir de template na página inicial), ou acesse diretamente /automations/templates
3. Explore a galeria de templates — cada template é uma automação pré-configurada para um fluxo de trabalho comum
4. Clique em um template para preencher o editor com seu gatilho, GitHub Action e limites sugeridos
5. Personalize a configuração (por exemplo, selecione seu canal do Slack ou repositório) e clique em Criar automação

​

Como usar linguagem natural

​

Configurando gatilhos

​

Gatilhos do Slack

• Mensagem do Slack: Dispara com novas mensagens. Uma condição de canal é adicionada por padrão; você pode removê-la para corresponder a mensagens de vários canais, mas, nesse caso, cada grupo de condições precisa de pelo menos um outro filtro (por exemplo, o texto da mensagem ou o tipo de remetente — Incluir respostas em thread sozinho não é suficiente).
• Grupo de usuários mencionado: Dispara quando um grupo de usuários do Slack (por exemplo, @oncall) é mencionado. Selecione o grupo ou informe o ID dele no Slack (que começa com S) e, opcionalmente, restrinja o gatilho a canais específicos.
• Reação do Slack: Dispara quando uma reação de emoji específica é adicionada a uma mensagem (e.g. 🚨 para incidentes). Você pode filtrar pelo nome da reação e pelo canal.

​

Gatilhos do GitHub

• Problema: Dispara em eventos de problema (aberto, fechado, reaberto, editado, com rótulo).
• Comentário em problema: Dispara quando um comentário é publicado em um problema do GitHub. É comumente usado com a condição starts_with "/devin", para que os usuários possam digitar /devin em qualquer problema e acionar o Devin.
• Pull request: Dispara em eventos de PR (abertura, sincronização etc.).
• Revisão de pull request: Dispara quando uma revisão é enviada em um PR.
• Comentário de revisão de pull request: Dispara em comentários individuais da revisão.
• execução de verificação: Dispara quando uma verificação de CI é concluída. Filtre por conclusion = failure para corrigir automaticamente builds com falha.
• Push: Dispara com pushes para uma branch.

​

Gatilhos do GitLab

• Merge request: acionado em ações de MR (aberto, fechado, com merge, reaberto, aprovado, atualizado).
• Comentário em MR: acionado quando um comentário (nota) é publicado em um merge request, incluindo threads de revisão de diff.
• Problema: acionado em ações de problemas (aberto, fechado, reaberto, atualizado).
• Comentário em problema: acionado quando um comentário é publicado em um problema.
• Push: acionado em pushes para uma branch.
• Pipeline: acionado quando um pipeline atinge um determinado status — filtre por status (por exemplo, failed) para corrigir automaticamente pipelines com falha.

​

Gatilhos do Linear

• Problema criado: É acionado quando um novo problema é criado na equipe selecionada.
• Rótulo adicionada: É acionado quando uma rótulo é aplicada a um problema (por exemplo, bug, devin).
• Status alterado: É acionado quando o status de um problema é alterado (por exemplo, movido para “Em andamento”).
• Prioridade alterada: É acionado quando a prioridade de um problema é alterada.
• Atribuído: É acionado quando um problema é atribuído a alguém.
• Problema movido: É acionado quando um problema é movido para outra equipe — o filtro de equipe do gatilho corresponde à equipe de destino.

​

Gatilhos do Jira

• Issue created: acionado quando um novo problema é criado.
• Issue updated: acionado quando os campos de um problema são alterados.
• Label added: acionado quando um rótulo é aplicado a um problema.
• Status changed: acionado quando o status de um problema muda.
• Assigned: acionado quando um problema é atribuído a alguém.
• Comment created or edited: acionado quando um comentário é adicionado ou editado em um problema.

​

Gatilhos por agendamento

• Recorrente: Defina a frequência (por hora, diária, semanal) e o horário. Internamente, os agendamentos usam o formato RRULE do iCalendar. Escolha Agendamento personalizado para criar uma recorrência personalizada (repetir a cada N minutos/horas/dias/semanas/meses) ou insira diretamente uma string RRULE em formato bruto (e.g. FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0) para intervalos mais complexos.
• Executar uma vez: Dispara uma única vez em uma data e horário futuros específicos e depois é desativado automaticamente. Útil para uma tarefa pontual com atraso programado — e.g. “acorde Devin em 12 horas para executar uma tarefa”. Escolha a data e o horário (o padrão é uma hora a partir de agora); eles devem estar no futuro.

​

Gatilhos de webhook

1. Crie uma automação com um gatilho Webhook
2. Copie a URL e o segredo do webhook exibidos na configuração do gatilho
3. Configure seu sistema externo (PagerDuty, Datadog, Sentry ou qualquer ferramenta personalizada) para enviar requisições HTTP POST para esta URL
4. Opcionalmente, adicione um filtro de payload — um padrão regex ao qual o corpo da requisição deve corresponder para que a automação seja acionada

• cabeçalho X-Webhook-Secret: <secret>
• cabeçalho Authorization: Bearer <secret>
• parâmetro de consulta ?secret=<secret>

​

Segredo do webhook

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

​

Verificações Preflight

​

Filtro de LLM

​

Configurar e testar um script Preflight

1. Crie uma automação ou edite uma existente e configure os gatilhos e as condições dela.
2. Clique em Add a step before the agent runs, abaixo da seção de gatilho, e selecione Run a script no cartão Before the agent runs.
3. Clique em Edit script, escolha Python, Node (JavaScript) ou Bash no seletor de runtime e edite o script inicial.
4. Se necessário, use Select secrets no editor de script para anexar segredos da organização. Somente os segredos selecionados são injetados como variáveis de ambiente. Para salvar ou testar um script com segredos anexados, é necessário ter permissão para gerenciar os segredos da organização.
5. Defina Timeout (seconds) no cartão: o padrão é 60 segundos, e o intervalo permitido vai de 1 a 300 segundos. Por padrão, o script usa o Minimal environment; se houver snapshots de máquina disponíveis, o seletor Environment também permite escolher um snapshot da organização com as suas dependências.
6. No editor de script, escolha um evento em Test against e clique em Run. Você pode testar o script não salvo com uma amostra de um gatilho configurado ou com um evento recente de uma automação existente. Revise o resultado, os logs e, no caso de itens emitidos, a prévia de quantos seriam executados, quantos seriam duplicados e quantos seriam adiados.
7. Clique em Save script para aplicar as alterações do editor e, em seguida, clique em Criar automação ou salve a automação para persistir a configuração.

​

Entrada e saída do 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)

​

Itens, estado e limites do script

• Prevenção de duplicatas: O id de um item identifica uma unidade de trabalho dentro desta automação, não apenas uma entidade. {"id": "INC-1"} é processado uma única vez; adicione uma version, como o timestamp de atualização na origem, para processar uma nova ocorrência desse incidente. Sem um id, o Preflight identifica o item por um hash do seu conteúdo, então alterar o conteúdo pode gerar uma nova execução.
• Limite de itens por execução: Por padrão, no máximo 10 novos itens são despachados por execução; o limite máximo do sistema é 50. Itens que excedem o limite não são processados nem agendados automaticamente. A próxima execução do seu script precisa emiti-los novamente. Não avance um cursor além do trabalho adiado só porque ele apareceu no seu output.
• Resultados anteriores: Use LAST_RUN_FILE para distinguir trabalhos em execução, concluídos com sucesso, com falha ou pulados. Quando a execução de um item falha, ele é liberado, e uma execução posterior do script pode emiti-lo novamente.
• Estado persistente: As execuções reais de script de uma automação ocorrem uma de cada vez. Scripts com falha não avançam o estado salvo nem marcam itens como processados. Clear state limpa tanto o estado JSON salvo quanto o histórico de itens já processados; após essa redefinição, itens processados anteriormente podem ser executados novamente.
• Limites de tamanho: O código-fonte e o output do script são limitados a 256 KiB cada; o estado salvo, a 64 KiB; e os logs capturados, a 1 MiB.
• Falhas: Um código de saída diferente de zero, timeout, output ou estado inválido, ou uma falha de infraestrutura interrompe o evento antes de suas Ações. Não há nova tentativa automática do script para esse evento; um acionamento posterior pode executá-lo novamente.
• Acesso à rede: A VM do script segue as restrições de rede da automação e o perfil de segurança aplicável. Por exemplo, para consultar um serviço externo de alertas, o host dele precisa estar permitido. Anexar um segredo não concede acesso à rede.

​

Configurando GitHub Actions

​

Iniciar sessão

• Prompt: As instruções que Devin seguirá. Escreva como se fosse um prompt comum do Devin.
• Playbook (opcional): Use @playbook-name no seu prompt para incluir um playbook com instruções adicionais.
• Tags (opcional): Adicione tags às sessões criadas por esta automação para facilitar a filtragem.

​

Enviar mensagem para uma sessão

​

Triagem do Devin (monitor)

​

Notificação por email

• Sempre — a cada execução
• Em caso de falha — somente quando a sessão falhar ou ocorrer um erro
• Em caso de sucesso — somente quando a sessão for concluída com sucesso

​

Limites e mecanismos de proteção

​

Limite de ACU

​

Limite de invocação

​

Enfileiramento

• Concurrent runs: o número máximo de execuções simultâneas desta automação. Os eventos excedentes aguardam na fila. Uma execução deixa de contar para o limite assim que sua sessão termina e passa a aguardar novas instruções.
• Queue depth: o número máximo de eventos que podem aguardar na fila. Os eventos que chegam quando a fila está cheia são descartados.

​

Política de rede

​

Integrações MCP

​

Acesso às ferramentas do Slack

​

Atividade e monitoramento

• Invocações recentes com data e hora
• Se cada invocação foi bem-sucedida ou ignorada
• Links para as sessões do Devin que foram criadas
• Mensagens de erro para invocações que falharam

​

Ativar e desativar

​

Templates