Revisão de Código do Discourse

:discourse2: Resumo Discourse Code Review permite revisar commits do GitHub no Discourse.
:hammer_and_wrench: Link do Repositório https://github.com/discourse/discourse-code-review
:open_book: Guia de Instalação Como instalar plugins no Discourse

Recursos

O que é?

O plugin Discourse Code Review oferece integração bidirecional com repositórios de código do GitHub. Ele permite que sua equipe revise commits de um repositório aproveitando os recursos e plugins do Discourse, como atribuição, whispers, notificações, fluxos de trabalho personalizados, entre outros. Cada commit em um repositório se torna um tópico. As respostas ao tópico são espelhadas no GitHub. A integração é bidirecional, o que significa que você pode comentar no Discourse e ver o comentário no GitHub, ou comentar no GitHub e ver no Discourse.

Ele oferece um fluxo de trabalho muito poderoso para equipes que precisam revisar todos os commits de qualquer número de repositórios.

Ele permite garantir que vários membros da equipe estejam cientes de todas as alterações aplicadas aos repositórios. Você pode marcar commits para acompanhamento, atribuir trabalho de revisão e muito mais.

Nota: Ao visualizar um tópico que pode ser aprovado, você pode usar o botão y do seu teclado para aprovar commits mais rapidamente.

Posso ver em ação?

O Discourse mantém o site https://review.discourse.org/, que é público e qualquer pessoa pode se cadastrar usando credenciais do GitHub. O site exibe apenas um subconjunto de recursos para membros não funcionários. Um exemplo mais completo pode ser:

No GitHub, o mesmo tópico se parece com isto:

Configuração

O plugin depende de webhooks do GitHub para descobrir repositórios e alterações neles. Para uma configuração mínima, você precisará definir a seguinte configuração com uma string secreta.

code review github webhook secret

Depois de definido no seu repositório do GitHub, configure um webhook com:

URL do Payload: https://SEU_DISCOURSE/code-review/webhook
Tipo de Conteúdo: application/json
Segredo: o valor de code review github webhook secret
Tipos de Evento:

  • Comentários de commits
  • Comentários de issues
  • Pull requests
  • Revisões de pull requests
  • Comentários de revisão de pull requests
  • Pushes

O plugin fornece as seguintes configurações de site adicionais:

code review api username: O GitHub é muito restritivo com o número de solicitações de API anônimas que permite. Esta configuração permite que você use as chaves de conta de um usuário do Discourse para solicitações /comments e /commit. Isso reduz drasticamente as chances de atingir os limites de taxa.

code review catch up commits: número de commits para “compensar” e criar tópicos quando você encontrar um novo repositório.

code review default parent category: escolha uma categoria pai padrão para as categorias criadas pelo plugin

code review pending tag: Tag para aplicar a todos os commits não revisados, pending por padrão

code review approved tag: Tag para aplicar a commits aprovados, approved por padrão

code_review_followup_tag: Tag para aplicar a commits de acompanhamento, follow-up por padrão

code review allow self approval: Os funcionários podem aprovar seus próprios commits?

code review default mute new categories: Novas categorias criadas pelo code review estão silenciadas para os usuários por padrão

code review skip duration minutes: Clicar no botão de pular em um commit impedirá que esse commit apareça novamente pelo número de minutos definido por esta configuração.

CHANGELOG

TODO

Extras

Como o Discourse Usa Este Plugin

TL;DR - Este plugin foi projetado para complementar o uso da equipe do Discourse do GitHub para revisão de código.

Mais Informações

De @sam:

  • Ainda usamos PRs usando a interface do GitHub e adoramos fazer PRs para muitas alterações. Nada mudou aqui. O GitHub é fantástico, adoramos o GitHub. Eles têm um fluxo de trabalho excelente para alterações que ainda não foram integradas. No entanto…

  • O fluxo de trabalho do GitHub para alterações que foram commitadas diretamente no repositório é terrível.

  • A revisão preenche uma lacuna que simplesmente não pode ser preenchida com o GitHub hoje. Gostaríamos que pelo menos um membro da equipe revisasse cada alteração feita em nossos vários repositórios git de propriedade do Discourse. Se formos usar a interface fornecida pelo GitHub, ninguém nunca será permitido fazer nada além de pull requests. Isso nos desaceleraria enormemente.

  • Precisamos da capacidade de nos comunicar privadamente sem que todo o mundo saiba, em relação a certas alterações. Por exemplo: É melhor implantarmos este correção incrível na <inserir nome da grande empresa> o mais rápido possível, @sam você pode cuidar disso?

  • Precisamos da capacidade de aprovar alterações feitas ou solicitar acompanhamento, algo que a interface do GitHub não oferece.

  • Precisamos da capacidade de atribuir commits específicos a um usuário. Digamos que @sam faça um commit contendo alguns erros. É bom que possamos atribuir diretamente a ele aquele commit específico, marcá-lo para acompanhamento e depois acompanhar se o acompanhamento foi realizado.

  • O Discourse é bastante fantástico em toda essa coisa de conversa, e os pequenos recursos fazem uma grande diferença. Eu posso ver quando as pessoas estão digitando. Nunca preciso atualizar as páginas para que as alterações apareçam. Citações são realmente boas, uploads de imagens são bons, e assim por diante.

  • O Discourse é realmente bom em gerenciar o estado de leitura, você tem garantias muito fortes de que leu cada coisa uma vez. Com o GitHub, não tenho ideia de quais commits li e quais não li. Temos uma maneira incrivelmente eficiente de lidar com a chuva de informações.

E a lista continua…

Então, a revisão atua como um complemento ao GitHub. No momento, usamos o GitHub para lidar com alterações que ainda não foram integradas. E usamos a revisão para lidar adequadamente com as alterações que já foram integradas.

71 curtidas

Estou tentando entender o propósito deste plugin. Tenho a impressão de que preciso de algo assim, mas estou com dificuldades para ver como isso ajuda na eficiência. Quando alguém aprova um pull request e o mescla em um branch, o que há no seu processo que faz com que essa aprovação exija outra aprovação para o commit associado?

O GitHub não oferece isso em relação a commits porque a suposição é que isso já foi tratado no pull request. O que estou perdendo?

É porque há pessoas na sua equipe que podem aprovar pull requests, mas não são qualificadas para tomar a decisão final sobre esse commit em relação a um lançamento real? O propósito é que os pull requests possam ser mesclados e revisados rapidamente sem esperar por alguém que tenha a palavra final, com a garantia de que essa pessoa ou equipe revisará o commit antes que um lançamento seja criado?

Ou é principalmente para apoiar discussões privadas em repositórios públicos?

Eu adoraria ter mais insights sobre os benefícios de usar este plugin no seu fluxo de trabalho. Obrigado!

Era principalmente uma relíquia de fluxos de trabalho anteriores no Discourse.

Antigamente, usávamos para aprovação retroativa de conjuntos de alterações.

Hoje em dia, as coisas passam pelos canais de PR, então não usamos muito o plugin.

1 curtida