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 precise solicitá-la a cada vez. Ela é executada em um horário agendado ou quando algo acontece: um pull request é aberto, uma issue é registrada, ou uma verificação ou implantação falha.

Todas as automações são listadas na fábrica, em Automações, com informações sobre o que as dispara e o que fazem. Crie uma em Novo trabalho: selecione Automação e depois escolha quando ela será executada.

  • 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 agendamentoEm um horário definido, em intervalos ou uma vez agoraSolicite ao Sentry novos erros a cada hora e abra uma tarefa para cada um deles.
Algo aconteceQuando GitHub ou Coroid enviam o eventoReveja todo pull request aberto em um projeto

Use um agendamento quando o gatilho realmente for relacionado ao tempo, ou quando o item a ser monitorado estiver em outro sistema que não envie eventos Coroid, como Sentry ou Jira. O agendamento consulta esse sistema por meio do seu Servidores MCP e abre trabalho 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 da implantação falham
  • Uma versão é revertida

Mensagens do Slack e Telegram, novas issues do Jira e eventos gerados pelos seus próprios sistemas precisam de um filtro ou de uma conta de serviço. Inicie-os a partir de um modelo em Configurações, em Automação, ou altere o evento de uma automação no seu editor. Veja Ganchos.

O que ela faz

Quando seu evento é acionado, uma automação realiza uma de três ações:

  • Reveja o pull request. O Coroid Check revisa-o e publica sua análise em GitHub, com comentários nas linhas encontradas e uma verificação chamada Coroid Revisão. Disponível para pull requests que são abertos ou atualizados.
  • Transforme-o em trabalho. O evento é registrado como uma solicitação. Depois que a Qualificação aprovar, Coroid cria a tarefa ou o plano. Disponível para issues e para comentários que mencionam Coroid.
  • Siga o resumo. Um agente segue o resumo que você escreveu, com acesso somente de leitura, e pode abrir tarefas. Disponível para todos os eventos.

Nenhum deles altera seu código diretamente. O trabalho aberto por uma automação passa pelo mesmo processo de especificação, planejamento, construção, verificação e revisão que qualquer outra coisa, e resulta em um pull request que você aprova.

Reveja todo pull request

Para fazer com que o Coroid revise pull requests abertos por pessoas, não apenas os próprios:

  1. Abra Novo trabalho e selecione Automação.
  2. Escolha o projeto ou deixe em branco para abranger todos os projetos.
  3. Em Gatilho, selecione Quando algo acontece. Em Evento, escolha Pull request aberto e selecione Reveja o pull request.
  4. Dê um título e um breve resumo e continue.

A automação revisa cada novo pull request e cada atualização dele nesse projeto. O repositório precisa do GitHub App, e o projeto não deve estar configurado como Local apenas. Pull requests provenientes de tarefas do Coroid não são revisados novamente: a revisão deles faz parte da própria tarefa.

Você também pode ativar Pull requests para o projeto em Controle de Qualidade. Assim, as verificações do projeto também são executadas em cada pull request, e o Coroid Check revisa-o como parte da mesma execução.

Monitorando uma automação

Abra uma automação na fábrica para ver cada execução: quando foi feita, 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 tudo o mais. 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. "Uma verificação falhou" é acionado constantemente em um repositório movimentado. "Esta verificação falhou no branch base" é acionado quando algo está realmente errado.
  3. Observe o que ela produziu. Se uma automação abriu vinte tarefas e você mesclou duas, ela está gerando ruído e gastos, não valor.

A medida honesta de uma automação é a quantidade de trabalho que ela abre e que é mesclado, não a frequência com que é acionada.

Sentinel

Versões anteriores desta documentação descreviam o Sentinel, um monitor que vigia uma condição. Não se trata de um recurso separado. Uma condição é ou um evento, que uma automação pode executar, ou algo que um agendamento verifica.