O Que É uma Reexecução em CI? Explicação
Uma reexecução roda de novo um job, step ou workflow inteiro de CI após uma falha, na suposição de que a falha pode não se repetir.
O botão "reexecutar jobs que falharam" é um dos recursos mais clicados em CI, e essa frequência é, em si, um sinal. Reexecuções são a prima manual dos retries automáticos: úteis contra falhas transitórias, mas uma muleta que esconde problemas reais quando usada de forma reflexiva.
O que uma reexecução faz
Uma reexecução recomeça o trabalho que falhou. Dependendo da plataforma, você pode reexecutar um único job que falhou, apenas os jobs que falharam em um workflow ou tudo. O código em teste permanece inalterado; você está apostando que a falha não foi realmente sobre o código.
Manual vs automática
Uma reexecução manual é um humano clicando um botão após um build vermelho. Uma reexecução automática (um retry) acontece sem intervenção. Ambas servem a falhas transitórias, mas uma reexecução humana também custa uma troca de contexto e um atraso, que é exatamente o custo que os retries automáticos removem.
Quando uma reexecução é legítima
Reexecutar é razoável quando você tem bom motivo para acreditar que a falha foi transitória: um timeout de rede logado, um 503 de registry, um out-of-memory kill em um runner carregado. O mesmo job, rodado de novo, tem chance genuína de passar.
Quando ela esconde problemas
Reexecutar reflexivamente todo build vermelho é um sinal ruim. Se uma reexecução "conserta" um teste flaky, o teste continua quebrado; você apenas o adiou. E uma reexecução que faz passar uma falha determinística nunca acontece, então reexecutar essas só desperdiça minutos. Reexecuções frequentes são um sinal para medir e corrigir a flakiness, não para normalizá-la.
A perspectiva da Latchkey
Os managed runners com autocorreção da Latchkey transformam as reexecuções legítimas, de falha transitória, em automáticas: quando um job falha em um problema transitório ou mecânico detectado, o runner faz retry para que uma instabilidade isolada não faça seu build falhar, removendo o clique manual e a troca de contexto.
Principais conclusões
- Uma reexecução roda de novo um job, workflow ou step que falhou.
- Reexecuções manuais custam a um humano uma troca de contexto; as automáticas não.
- Reexecuções são legítimas contra falhas transitórias.
- Reexecuções reflexivas escondem testes flaky e problemas reais.