Documentação

Verificações, execuções e resultados

Ler uma execução de verificação, triar os achados e decidir quais ações tomar.

Uma verificação é uma única verificação. Uma execução é uma execução das verificações em uma política contra uma alteração. Uma achado é algo que uma verificação relatou.

Os achados de uma tarefa ficam na seção de Controle de Qualidade , e cada execução é monitorada em Configurações → Atividade.

Lendo uma execução

Uma execução exibe cada verificação, seu resultado e sua saída. Quando uma tarefa falha na verificação, a execução é onde você descobre o motivo.

Leia-a de cima para baixo. A primeira verificação com falha geralmente é a real — falhas posteriores costumam ser consequências. Uma falha de compilação seguida por doze falhas de teste representa um problema, não treze.

Achados

Os achados vêm de agentes revisores, scanners e portas de avaliação. Cada um indica o que foi encontrado, onde e sua gravidade. Um achado relacionado a uma tarefa permanece vinculado a ela. Uma falha de teste que não pertence a nenhuma tarefa fica na Factory sob Revisão, onde você pode corrigi-la ou aceitá-la com um motivo. Uma verificação que não pode ser executada em um projeto, como testes unitários sem um framework de teste, informa isso na sua linha no Controle de Qualidade.

Seu ciclo de vida:

  1. Gerado por uma verificação ou por um revisor.
  2. Encaminhado — achados corrigíveis são devolvidos ao agente desenvolvedor como retrabalho; os demais são anexados ao pull request.
  3. Resolvido — corrigido, aceito ou suprimido.

Geradas

  • Uma porta de aviso
  • O agente revisor
  • Um scanner conectado

Encaminhadas

Passíveis de correção

Retorna ao desenvolvedor como retrabalho

Tudo o mais

É anexado ao pull request

Resolvidas

  • Corrigidos

    A alteração resolve o problema

  • Aceitos

    É verdade, mas não vale a pena agir aqui. Indique o motivo.

  • Suprimidos

    É um falso positivo ou regra que não se aplica. Indique o motivo.

Observações corrigíveis são tratadas durante a execução. O restante chega ao pull request, e toda observação é resolvida, aceita ou descartada, com motivo para as duas últimas.

Triagem

A pergunta para cada achado não é "isso é verdade?" mas sim "isso muda o que acontecerá a seguir?"

  • Corrigir agora — correção, segurança ou qualquer coisa que causaria reprovação na revisão.
  • Aceitar — verdadeiro, mas não vale a pena agir agora. Registre o motivo.
  • Suprimir — falso positivo ou regra que não se aplica a esse código.

Suprima deliberadamente e com um motivo. Uma supressão sem explicação é indistinguível de alguém silenciando uma verdade inconveniente, e seis meses depois ninguém saberá qual dos dois foi.

Quando há muitos achados

O volume é um sinal sobre a configuração, não sobre a qualidade do código.

Uma verificação que dispara na maioria das alterações não está encontrando problemas — está descrevendo sua base de código. Ou a regra não corresponde às suas convenções, ou descreve uma dívida técnica que você decidiu tolerar. Ambos significam que a verificação tem o formato errado.

Achados e portas

Um achado de uma porta de orientação é informação. O mesmo achado de uma porta bloqueante interrompe a tarefa. O achado é idêntico; a política decide seu custo.

Essa é a alavanca a ser usada quando uma verificação está correta, mas é muito agressiva: altere sua severidade em vez de removê-la. Veja Políticas e portas de qualidade.