heydeer
Revisões no GitHub

Revisões de acompanhamento

Após a primeira revisão de um pull request, o HeyDeer revisa o que mudou e verifica novamente as preocupações anteriores. Saiba como isso funciona e como recusar um problema encontrado.

Revisar apenas as alterações novas

Revisar apenas as alterações novas vem ativado por padrão. Essa opção fica em Configurações do espaço de trabalho → Regras de revisão → Como revisar ou nas Regras de revisão de um repositório. Ela vale para revisões automáticas e solicitadas.

Uma revisão posterior procura novos problemas apenas no que os próprios commits do pull request alteraram desde a última revisão bem-sucedida do HeyDeer. Ela também verifica novamente os problemas encontrados nessa revisão, e os que ainda se aplicam contam para a verificação e para a aprovação.

Commits trazidos da branch base por merge ou rebase ficam de fora, mas as resoluções de conflito são revisadas. Verificações do repositório adicionadas ou editadas desde a última revisão se aplicam ao pull request inteiro.

O roteiro de uma revisão posterior continua cobrindo todo o PR e marca os grupos cujos arquivos mudaram desde a última revisão.

Preocupações anteriores

Uma preocupação anterior é um problema que o HeyDeer levantou em uma conversa de revisão em linha iniciada por ele em uma revisão anterior. Cada revisão posterior verifica novamente as que estão em aberto com base no código atual.

As preocupações que ainda se aplicam são listadas em Preocupações anteriores a resolver. Conversas antigas que o HeyDeer não consegue vincular a um problema encontrado são listadas em Preocupações anteriores a confirmar; resolva-as quando não se aplicarem mais.

Preocupações anteriores em aberto ou não confirmadas aparecem no resumo da verificação e bloqueiam a aprovação automática. Com Reprovar a verificação quando forem encontrados problemas ativado, elas também reprovam a verificação.

O HeyDeer só resolve conversas que ele mesmo iniciou. Com Marcar conversas atendidas do HeyDeer como resolvidas ativado (o padrão), ele as resolve quando o código atual corrige a preocupação ou mostra que ela estava errada. Uma resposta dizendo que foi corrigido não basta.

As alterações incorporadas a partir de um PR de correção são verificadas novamente da mesma forma na próxima revisão do PR original.

Recusar um problema encontrado

Responda na conversa do problema encontrado e explique o motivo, por exemplo que o comportamento é intencional ou está sendo acompanhado em uma issue, ou resolva a conversa. Quando alguém com acesso de escrita ou superior o recusa, o HeyDeer deixa de verificar a preocupação e não a levanta de novo, mesmo que o código ainda tenha o problema. As outras respostas são lidas como contexto.

Quando o HeyDeer revisa o pull request inteiro

  • A primeira revisão, ou qualquer revisão enquanto Revisar apenas as alterações novas estiver desativado.
  • Alguém comentou @heydeer full review.
  • A branch base mudou desde a última revisão.
  • Alguém solicitou outra revisão de um commit que o HeyDeer já revisou, por exemplo, depois de adicionar contexto.
  • A última revisão tinha observações da revisão sobre problemas omitidos, verificações correspondentes em excesso ou uma avaliação incompleta, ou pediu esclarecimentos.
  • O GitHub não tem mais o último commit revisado.

O resumo da verificação e a linha Revisado da revisão no HeyDeer mostram se uma revisão cobriu Alterações novas ou o PR inteiro.

Discussão existente

O HeyDeer lê a descrição do PR como contexto. Comentários, o corpo das revisões e as conversas de revisão de outras pessoas nunca contêm uma preocupação anterior nem impedem o HeyDeer de publicar um problema encontrado.