Ferramentas de Desenvolvimento
A área de Configurações dedicada a ferramentas que atuam sobre o código de quem usa a plataforma. Nasce com uma só: o revisor de Pull Request.
Ferramentas de Desenvolvimento
Área de Configurações da organização dedicada a ferramentas que atuam sobre o código de quem usa a plataforma, e não sobre a operação do dia a dia. Nasce com uma ferramenta só: o revisor de Pull Request.
O que dá para fazer
- Autorizar a plataforma na sua conta ou organização do GitHub.
- Ligar o revisor por repositório — sem instalar nada do seu lado, sem precisar guardar segredo, sem manter configuração dentro do repositório.
- Acompanhar, repositório a repositório, o estado atual e três números dos últimos 30 dias.
- Ver o histórico de revisões, uma linha por Pull Request.
- Escolher o peso da revisão na lista de checagens do GitHub, entre três opções: sem verificação nenhuma, uma verificação informativa (sempre verde) ou uma que fica vermelha quando há achado grave.
Do que este módulo cuida
Hoje, uma funcionalidade só: o revisor de Pull Request. Antes dele, quem quisesse revisão automática montava e mantinha a própria automação no GitHub, com o segredo e a configuração por conta. Agora é um agente da própria plataforma — ele não aparece na lista de agentes, mas passa pela mesma fila e pela mesma cota de qualquer outro.
O módulo nasce pequeno de propósito: uma ferramenta, uma tela. Cresce se outras ferramentas de desenvolvimento vierem a existir, o que ainda não é o caso.
O que ele faz, e o que não faz
Ele nunca aprova, nunca pede mudanças e nunca barra a Pull Request sozinho — só comenta. O peso que a revisão tem na lista de checagens do GitHub você escolhe entre três opções, e só a última delas — a que fica vermelha com achado grave — transforma a revisão em algo capaz de travar um merge. Nas outras duas, o revisor opina e a decisão continua inteira com quem revisa.
Três tipos de Pull Request ficam de fora por padrão: as em rascunho, as vindas de cópias do repositório e as abertas por outros robôs. Para a cópia do repositório a razão é concreta: revisar de verdade significa rodar o código da própria Pull Request — testes e dependências —, e código de origem que ninguém da organização controla não entra nessa porta sem alguém decidir. Cada um dos três é um interruptor que você liga se quiser.
Dois ajustes no GitHub não têm caminho automático e precisam ser feitos à mão: assinar o aviso de novas Pull Requests e liberar a escrita da verificação. Eles não são seus. São feitos uma única vez, do nosso lado, no aplicativo que serve todas as organizações — do seu lado, os passos são os três de Como ligar. Se algum deles ainda estiver pendente, a própria tela avisa, em vez de deixar você achar que ligou e esperar por uma revisão que não vem.
Thread e mensagens
A conversa é a unidade de trabalho: guarda o histórico, hospeda as execuções e pode ser renomeada, fixada, arquivada e marcada como lida. Cada conversa pertence a um agente…
Revisor de Pull Request
O revisor nativo de Pull Requests: comenta achados de segurança, qualidade e análise automática em toda PR de um repositório ligado, sem configuração do lado de quem usa.