ci-guard
Diagnosticar antes de repetir.
Classifica falhas de CI para tornar a decisão de rerun mais informada.
Problema
Retries cegos podem esconder falhas e consumir minutos de CI.
Minha contribuição
Desenvolvimento e manutenção do projeto pessoal.
THE PIPELINE / SYSTEM MAP
ci-guard
Uma falha de CI vira uma decisão classificada, com orçamento e verificação.
Etapa 1 / 6
Snapshot do CI
Capturar checks e logs da falha antes de qualquer tentativa de rerun.
Etapa 2 / 6
Classificação
Distinguir falha da branch, infraestrutura, teste flaky, dependência e desconhecido. Scripts Python não chamam LLM.
Etapa 3 / 6
Limite de retry
Falhas elegíveis só podem repetir dentro dos limites por job, PR e minutos.
Etapa 4 / 6
Verificar o verde
Um teste flaky que ficou verde precisa de verificação adicional no mesmo SHA.
Etapa 5 / 6
Ledger & decisão humana
Registrar histórico de flakiness; recomendar quarentena quando os critérios se aplicam. A pessoa decide.
Etapa 6 / 6
Corrigir ou investigar
branch_failure exige correção; unknown exige leitura manual dos logs. Orçamento esgotado interrompe o retry.
Corrigir código, investigar ou repetir são caminhos diferentes.
Conexões e condições
- Snapshot do CI → ClassificaçãoReúne evidências
- Classificação → Limite de retryFalha elegível para retry
- Classificação → Corrigir ou investigarBranch ou desconhecido
- Limite de retry → Verificar o verdeFlaky ficou verde
- Limite de retry → Corrigir ou investigarLimite esgotado
- Verificar o verde → Ledger & decisão humanaRegistra a verificação
Percurso ilustrativo dos componentes documentados, sem execução dos projetos. Fontes consultadas em 2026-10-28.
Explore os componentes ou reproduza o percurso.
Decisão de engenharia
Separar falhas transitórias de problemas de código reduz decisões cegas.
Trade-off
Classificação exige regras observáveis e cuidado com falsos positivos.
Evidência
Scripts Python classificam falhas e aplicam limites de retry sem chamar LLM ou exigir API key, conforme o contrato público do projeto.
Documentação do projeto ↗