babysit

Sobre o babysit

Vigora um pull request ou ciclo de revisão até que ele esteja genuinamente pronto para ser mesclado, continuando a verificar em vez de parar após uma única passagem enquanto comentários ou threads de revisão permanecerem não resolvidos. O fluxo de trabalho identifica o número do PR, o branch e o branch base, confirma que o PR não é um rascunho e insere a capacidade de mesclagem, verificações, decisão de revisão, comentários e threads de revisão. Verificações pendentes são vigiadas até que sejam concluídas, com consultas em um intervalo prático de aproximadamente 30 a 60 segundos, a menos que o usuário solicite uma cadência diferente. Comentários novos e threads de revisão não resolvidos são lidos, com resumos do bot tratados como achados úteis e acionáveis, verificados contra o código.

Problemas reais são corrigidos em commits focados, testes ou builds relevantes são executados, as alterações são enviadas e o ciclo retorna para re-inspecionar o status. Threads de revisão obsoletas são resolvidas apenas após verificar que o código ou o artefato gerado agora aborda o comentário. O processo só é interrompido quando as verificações estão passando ou foram intencionalmente ignoradas, a decisão de revisão é aceitável, não restam comentários acionáveis e não restam threads de revisão não resolvidas.

A habilidade fornece receitas concretas do GitHub CLI e GraphQL. gh pr view com uma lista de campos JSON fornece um status grosseiro, incluindo estado, status de rascunho, capacidade de mesclagem, mergeStateStatus, reviewDecision, headRefOid e statusCheckRollup. O proprietário e o nome do repositório são resolvidos com gh repo view e jq antes das consultas GraphQL. Threads de revisão não resolvidas são buscadas com uma consulta GraphQL reviewThreads que inclui pageInfo para paginação, com um loop documentado que pagina os resultados usando endCursor enquanto hasNextPage for verdadeiro e filtra threads não resolvidos com jq. Uma mutação resolveReviewThread resolve um thread apenas quando a correção é verificada. As regras de operação incluem manter o observador em execução durante verificações longas, confirmar se os problemas relatados pelo bot são contra código obsoleto ou atual, verificar que o código-fonte e os artefatos gerados concordam antes de resolver, fazer uma varredura final fresca e relatar evidências concretas, como o SHA do commit mais recente, resultados das verificações, contagem de threads não resolvidas, testes executados e quaisquer arquivos locais sujos.

Perguntas Frequentes

Quando a habilidade para de vigiar um PR?

Apenas quando as verificações estão passando ou foram intencionalmente ignoradas, a decisão de revisão é aceitável, não restam comentários acionáveis e não restam threads de revisão não resolvidas. Não para após uma única passagem de verificação se os threads ainda estiverem abertos.

Com que frequência ele consulta o status?

Em um intervalo prático, geralmente de 30 a 60 segundos, a menos que o usuário solicite uma cadência diferente. O observador é mantido em execução enquanto as verificações longas ainda estiverem pendentes.

Como os threads de revisão não resolvidos são encontrados?

Com uma consulta GraphQL reviewThreads que inclui pageInfo, paginando os resultados usando o endCursor anterior enquanto hasNextPage for verdadeiro, filtrando então os threads onde isResolved é falso com jq.

Quando é seguro resolver um thread de revisão obsoleto?

Apenas após verificar que o código ou o artefato gerado agora aborda o comentário, usando a mutação resolveReviewThread. Para arquivos gerados distribuídos, o código-fonte e o artefato gerado devem ser confirmados como concordantes primeiro.

O que deve ser relatado no final?

Evidências concretas: o SHA do commit mais recente, nomes e resultados das verificações, a contagem de threads não resolvidos, testes executados e quaisquer arquivos locais sujos deixados intocados, após fazer uma nova varredura do status do PR, threads, comentários recentes e status do git.