VolundOS

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.

Atualizado em 08 de setembro de 2026

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.

On this page