Um pull request do Coroid passa por verificação antes de você vê-lo. Esta seção explica o que isso significa e como configurá-lo.
As camadas
A verificação não é algo único. Quatro camadas são executadas, cada uma respondendo a uma pergunta diferente.
Sua suíte de testes. O sinal mais confiável disponível, pois já codifica o que sua equipe considera importante. O Coroid a executa em um ambiente isolado para cada tarefa.
Portas de qualidade. Verificações definidas por políticas — cobertura, linting, análise de segurança e testes em navegador. As portas bloqueantes impedem a tarefa; as portas consultivas registram uma ocorrência e permitem que ela prossiga. Veja Políticas e portas de qualidade.
Revisão. Um agente revisor analisa o diff finalizado e gera ocorrências. Ocorrências corrigíveis retornam ao desenvolvedor como retrabalho; as demais são anexadas ao pull request.
Evidências. Implantações de pré-visualização, resultados de varredura e deltas de cobertura anexados diretamente ao próprio pull request, fazendo com que a verificação chegue junto com o código. Veja Evidências de revisão.
O que isso comprova e o que não comprova
A verificação confirma que a alteração faz o que foi descrito, não quebra o que já existia e atende aos padrões que você definiu.
Ela não comprova que a alteração é a coisa certa a ser construída. Isso é o que os critérios de aceitação no especificação servem para, e para o que serve sua revisão.
Uma alteração pode passar por todas as camadas e ainda assim estar errada. Manter essa distinção clara é o que torna o restante confiável — no momento em que a verificação é apresentada como julgamento, as pessoas param de revisar.
O objetivo de executá-la primeiro
Cada camada é executada antes da criação do pull request, então as falhas retornam como retrabalho dentro do processo em vez de resultar em um pull request que seria rejeitado.
É mais barato falhar no ambiente de trabalho do que na sua tela. Sua revisão deve ser a primeira pessoa a analisar, não a primeira visualização.
Por onde começar
Se você está configurando isso pela primeira vez:
- Certifique-se de que sua suíte de testes esteja funcionando — veja Configuração de build e teste. Nada mais importa se isso estiver incorreto.
- Defina uma política padrão da organização no nível padrão , não no nível mais restrito.
- Conecte os provedores de evidências que você já utiliza.
- Adicione as portas uma por uma, começando pelas consultivas.