O Que É uma Falha Transitória vs Determinística? Explicado
A distinção de confiabilidade mais importante em CI é transitória versus determinística: uma é ambiental e retentável, a outra está no seu código e precisa de correção.
Quase toda boa decisão sobre uma falha de CI decorre de uma única pergunta: executar isto de novo vai ter sucesso? Respondê-la corretamente diz se você deve retentar ou depurar. Errar significa ou retries desperdiçados em um bug real, ou investigação desperdiçada em um contratempo que passaria.
As duas classes
Uma falha transitória é causada pelo ambiente, um contratempo de rede, um timeout de registry, um kill por falta de memória, e se resolve sozinha, então um retry tem sucesso. Uma falha determinística é causada pelo código, configuração ou entradas, e se repete de forma idêntica a cada execução, então um retry é inútil. Toda falha de CI se encaixa em uma dessas.
O teste decisivo: reprodutibilidade
A reprodutibilidade é a linha entre elas. Execute o mesmo job de novo: se ele falhar da mesma forma toda vez, é determinística; se às vezes passa, é transitória. Essa única pergunta orienta a resposta correta de forma mais confiável do que ler a mensagem de erro sozinha.
Por que acertar isso importa
- Retentar uma falha determinística desperdiça minutos e atrasa a correção real.
- Depurar uma falha transitória desperdiça tempo humano caçando um não-bug.
- Classificar errado corrói a confiança: vermelhos reais são descartados, contratempos são investigados em excesso.
Sinais que sugerem transitória
Erros de rede e de registry, rate limits, kills por falta de memória, preempções e cancelamentos tendem a transitória, especialmente se não se reproduzem. Falhas de assertion, erros de compilação e de tipo, e arquivos ausentes tendem a determinística. A classe do erro somada à reprodutibilidade juntas dão um veredito confiante.
O ângulo Latchkey
Automatizar exatamente essa distinção é o cerne da autocorreção. Os runners gerenciados com autocorreção da Latchkey classificam as falhas, detectam as transitórias e mecânicas, e retentam automaticamente, para que um contratempo pontual não faça seu build falhar, ao mesmo tempo em que deixam as falhas determinísticas falharem rápido para você corrigir.
Principais conclusões
- Falhas transitórias são ambientais e retentáveis; as determinísticas são de código e precisam de correção.
- Reprodutibilidade é o teste decisivo: ela falha toda vez?
- Classificar errado desperdiça ou minutos de máquina ou tempo humano.
- A autocorreção automatiza essa classificação no nível do runner.