O revisor do PR não pode ser quem o escreveu
Agentes abrem PR como rascunho e marcam como pronto sozinhos. Um único agente revisa, e o merge continua comigo. O que quebrou até isso funcionar.
Meus agentes (programas configurados para executar tarefas) abrem PRs (pedidos para
revisar e incluir mudanças no código). Cada tarefa ganha um worktree (cópia separada
dos arquivos do projeto) a partir da branch develop (linha separada de trabalho). O PR
começa como rascunho. Só quem fez o trabalho decide quando está pronto. Depois, o
SENTINEL é o único agente autorizado a revisar. Só eu faço o merge (incorporo as
mudanças ao projeto). Abaixo conto o que quebrou até isso funcionar.
Rascunho e pronto
Rascunho quer dizer que o autor ainda está trabalhando. Pronto quer dizer que o pedido foi enviado para revisão. O SENTINEL não revisa rascunhos. Assim, o estado do PR já mostra quem precisa agir.
O erro foi meu. Os agentes terminavam o trabalho, conferiam e perguntavam se podiam marcar o PR como pronto. Eu acabava decidindo algo que não precisa de mim. Eu autorizo o merge, não o envio para revisão. Agora, o agente que fez o trabalho marca o PR como pronto depois de terminar e conferir. Não precisa perguntar. Pedir licença só atrasa o pedido.
Um revisor, um SHA
O SENTINEL tem três modos. Lite faz a primeira revisão de mudanças de até 150 linhas efetivas. Delta faz uma segunda revisão depois de uma decisão anterior em que confio. Full serve para os outros casos. Há um único revisor oficial. Assim, dois agentes não vão presumir que o outro conferiu o mesmo PR.
O veredito inclui o Reviewed-Head-SHA (identificador da versão exata do código que
foi lida).
Isso importa porque a aprovação vale apenas para aquela versão. Para mim, pronto quer
dizer aprovado na versão atual, com as verificações automáticas aprovadas nessa mesma
versão. Se alguém enviar outra versão do código depois do veredito, a aprovação deixa
de valer.
Sem essa referência, seria possível aprovar, receber mais uma mudança e incorporar
código que ninguém revisou.
Em 4 de agosto, a ADR-020 (registro de uma decisão sobre como o sistema é montado) registrou que o SENTINEL ganhou uma identidade própria de revisão no GitHub. Se o revisor publica como autor, o autor parece aprovar o próprio trabalho. Configurar essa identidade teve uma dificuldade. Credenciais digitais com permissões específicas devolviam 404 em repositórios privados quando a conta era só colaboradora. O erro 404 significa que o recurso não foi encontrado. Isso definiu como configurei a identidade.
Evidências no corpo do PR
Em 12 de agosto, um PR do vault recebeu o status CHANGES_REQUESTED (pedido de
alterações) duas vezes pelo mesmo motivo.
Eu tinha colocado todas as evidências num comentário. O revisor lê o corpo do PR, não
o comentário. Perdi duas rodadas porque a prova estava no lugar errado. As evidências
vão no corpo do PR.
Quem realmente faz o merge
Em 5 de setembro, medi quem estava fazendo os merges. Em 30 dias, 30 de cada 100 merges no repositório do assistente tinham meu nome. No repositório de operações, eram 2 de cada 100.
Medido em 5 de setembro. Parte dos merges com o meu nome foi feita por agentes usando as minhas credenciais.
Ver dados
| Repositório do assistente | 30 de 100 |
|---|---|
| Repositório de operações | 2 de 100 |
Nem todos os merges com meu nome foram feitos por mim. Alguns agentes usaram minhas credenciais. O nome no registro não mostrava quem tinha apertado o botão. Agora, uma proteção bloqueia os agentes, e eu faço o merge.
Commits de merge e autores fora da lista
A regra é usar merge commit. Ele registra a união de duas linhas de trabalho. Nunca uso squash, que junta as mudanças num único registro. O squash quebrou a comparação entre as mudanças.
Em 6 de setembro, descobri que o processo automático de revisão ignorava PRs de autores fora da lista autorizada. Um PR aberto por uma segunda conta de bot ficou sem revisão. Os registros também não mostravam o motivo.