Documentação

Automações

Trabalho que começa sem precisar de solicitação a cada vez, seja por agendamento ou quando algo acontece, e onde encontrá-lo.

Uma automação começa a trabalhar sem que ninguém a solicite, a cada vez. Ela é executada em um horário agendado ou quando algo acontece: um pull request é aberto, uma issue é registrada, uma verificação ou implantação falha.

Todas as automações são listadas na Factory, na seção Automações, com informações sobre o que as ativa e o que fazem. Crie uma em Novo trabalho: selecione Automação e defina quando será executada e qual será sua ação, usando suas próprias palavras.

  • AgendarHorário
  • Automação de eventosAlgo acontece.

Uma tarefa comum

Especificação, plano, construção, verificação, revisão. Usa um slot de agente; atribua-lhe prioridade menor.

P2P3

Um pull request

Ele não pode fazer merge nem commit na sua branch base.

Você aprova

A automação difere apenas no seu gatilho. O que ela abre é uma tarefa comum no caminho normal, portanto usa capacidade real e resulta em um pull request que você aprova.

Dois tipos de gatilho

GatilhoExecuçõesExemplo
Um agendamentoA cada poucas horas, ou diariamente, semanalmente ou mensalmenteSolicite ao Sentry novos erros a cada hora e abra uma tarefa para cada um.
Algo aconteceQuando GitHub ou Coroid enviam o eventoQuando uma tarefa falha, descubra o motivo e abra uma tarefa para corrigi-la.

Use um agendamento quando o gatilho for realmente o tempo, ou quando o elemento a ser monitorado estiver em outro sistema que não envie eventos Coroid, como Sentry ou Jira. O agendamento consultará esse sistema por meio do seu Servidores MCP e abre tarefas para o que encontrar. Veja Agendas.

Use um evento quando Coroid puder ser notificado no momento em que ocorrer. Ele realiza menos trabalho desnecessário do que um agendamento que fica perguntando constantemente.

Eventos que você pode escolher em Novo trabalho

Do GitHub, que requer o GitHub App:

  • um pull request é aberto, atualizado ou mesclado
  • uma issue é aberta
  • um comentário menciona Coroid; isso conta apenas quando o autor tem acesso de escrita ao repositório

Do Coroid:

  • uma tarefa, um plano, uma verificação de Qualidade, uma implantação ou uma verificação de integridade de implantação falham
  • uma implantação tem sucesso
  • uma versão é revertida

Os eventos gerados pelos seus próprios sistemas exigem uma conta de serviço, e os eventos do Slack, Telegram e Jira precisam de um filtro: altere o evento da automação no editor dela. Veja Ganchos.

O que ela faz

Um agente segue suas instruções. Ele pode ler o código do projeto e abrir tarefas, mas não altera nada diretamente. O trabalho que ele abre passa pelo mesmo processo de especificação, planejamento, construção, verificação e revisão que qualquer outro item, e termina em um pull request que você aprova.

Em um agendamento, uma automação pode, em vez disso, executar seus testes de navegador contra uma superfície de teste.

As automações permanentes que Coroid cria para você são interruptores no Controle de Qualidade, não algo para criar em Novo trabalho:

  • Revisar pull requests. Do Controle de Qualidade Pull requests o grupo executa as verificações do projeto em cada pull request (Coroid Controle de Qualidade) e inclui um comentário de Coroid Review sobre ele.
  • Transformar mensagens e issues em solicitações. Mensagens do Slack e Telegram, comentários do GitHub que mencionam Coroid e novas issues do Jira se tornam solicitações quando a fonte correspondente estiver ativada no Controle de Qualidade, na seção Antes que o trabalho comece. Veja Rastreadores de issues para Jira.
  • Acompanhar falhas. Uma tarefa com falha, uma implantação com falha e uma versão revertida têm um interruptor em Quando algo quebra.
  • Limpar dívida técnica existente. Um projeto Limpeza semanal de dívida técnica é um interruptor na linha Anti-slop dele.

Uma automação gerenciada por um interruptor indica isso em sua página na Factory, com um link para o interruptor. Pause-a ou desative-a ali; altere suas instruções e ela se tornará sua, após sua confirmação.

As automações criadas anteriormente que registram solicitações continuam em execução e são listadas na seção Automações. As automações que revisavam pull requests foram pausadas quando o Controle de Qualidade assumiu o Coroid Review.

Modelos do Novo trabalho

O Novo trabalho costumava oferecer modelos. Suas funções foram transferidas para os interruptores acima, e daqueles dois que postavam no Slack podem ser configurados com suas próprias palavras, indicando o canal. Eles postam por meio de um Servidor MCP que você conecta em Configurações, na seção Conexões: um agendamento pode usá-lo, e uma automação de evento pode usá-lo depois de permitir as ferramentas MCP no editor dela na Factory. As automações criadas a partir de um modelo continuam em execução como estão. Um link antigo para um modelo abre o interruptor que o substituiu, ou o Novo trabalho.

Monitorando uma automação

Abra uma automação na Factory para ver cada execução: quando foi executada, quanto custou, o que abriu e por que uma execução não foi concluída. A partir daí, proprietários e administradores podem pausá-la, testá-la, editá-la ou excluí-la. Todos na organização podem ver as automações e suas execuções.

Mantendo as automações úteis

O trabalho aberto por uma automação compete pelos mesmos slots de agente que qualquer outro item. Uma automação que dispara com frequência pode consumir sua capacidade silenciosamente.

  1. Dê a ela uma prioridade menor do que o trabalho solicitado por pessoas. P2 ou P3.
  2. Torne o gatilho específico. A mensagem "Uma verificação falhou" é disparada constantemente em um repositório com muito movimento. Já a mensagem "Esta verificação falhou no ramo base" é exibida quando há realmente um problema.
  3. Veja o que foi gerado. Se uma automação abrir vinte tarefas e você mesclar apenas duas, o resultado será ruído e custos desnecessários, e não valor agregado.

A métrica mais precisa para avaliar uma automação é a proporção de tarefas abertas por ela que são mescladas, e não a frequência com que ela é acionada.

Sentinel

Versões anteriores desta documentação descreviam o Sentinel como um monitor que detecta determinadas condições. Na verdade, ele não é um recurso separado. Uma condição pode ser um evento que aciona uma automação ou algo que um agendamento verifica.