O Que É uma Falha Mecânica em CI? Explicação
Uma falha mecânica é aquela enraizada na máquina ou na infraestrutura que executa o job, como um out-of-memory kill ou uma instância preemptada, e não no seu código.
Quando as pessoas dizem que um build "falhou", geralmente querem dizer que os testes falharam. Mas uma fração significativa das falhas nunca chega ao seu código: o runner ficou sem memória, o disco encheu, a instância foi reivindicada. Essas falhas mecânicas são ambientais e se comportam de forma muito diferente de erros de lógica.
O que conta como mecânico
- Out-of-memory kills (o processo recebe SIGKILL, muitas vezes aparecendo como exit code 137).
- Condições de disco cheio ou esgotamento de inodes no runner.
- Reivindicação de instância spot ou preemptível no meio do job (muitas vezes SIGTERM, exit 143).
- Falhas de provisionamento do runner e breves incidentes do provedor.
Falhas mecânicas vs lógicas
Uma falha lógica vem do seu código ou dos testes: uma assertion é falsa, um tipo não confere, um arquivo está ausente. Uma falha mecânica vem da máquina: ela ficou sem um recurso ou foi retirada. Falhas lógicas se reproduzem toda vez; as mecânicas geralmente não, porque dependem de condições transitórias de recurso.
Por que elas parecem confusas
Falhas mecânicas muitas vezes aparecem como sinais crípticos em vez de erros úteis. Um out-of-memory kill deixa apenas a palavra "Killed" e o exit code 137; uma preempção pode mostrar um cancelamento genérico. Sem contexto, essas falhas são classificadas erroneamente como testes flaky ou falhas aleatórias.
A resposta certa: retry
Como falhas mecânicas são ambientais, a resposta correta é geralmente fazer retry, idealmente em um runner novo com recursos adequados. Fazer retry de uma falha lógica é inútil, mas fazer retry de uma mecânica frequentemente passa, porque a condição transitória de recurso já passou.
A perspectiva da Latchkey
Falhas mecânicas são precisamente o que os managed runners com autocorreção da Latchkey foram feitos para pegar. A plataforma detecta falhas mecânicas e transitórias como out-of-memory kills, instabilidades de rede e timeouts de registry e automaticamente faz retry, de modo que uma instabilidade isolada não faça seu build falhar, enquanto falhas reais de código ainda falham rápido.
Principais conclusões
- Uma falha mecânica está na máquina ou na infraestrutura, não no seu código.
- Out-of-memory kills, disco cheio e preempções são exemplos típicos.
- Elas raramente se reproduzem, ao contrário das falhas lógicas (de código).
- A resposta certa é geralmente um retry, muitas vezes em um runner novo.