O Que É um Timeout de CI? Explicação
Um timeout de CI é um limite configurado que cancela um job ou step assim que ele roda por mais tempo que o permitido, para que um processo travado não prenda um runner para sempre.
Sem timeouts, um único job travado poderia prender um runner indefinidamente, bloqueando a fila e queimando minutos. Timeouts são uma válvula de segurança, mas também revelam problemas reais: um step que atinge o timeout ou é genuinamente lento, ou está em deadlock, ou está esperando por algo transitório que nunca chegou.
Por que timeouts existem
Um timeout limita por quanto tempo um trabalho pode rodar. Ele protege a capacidade compartilhada de um único job descontrolado, limita o gasto desperdiçado com um processo travado e dá ao pipeline um desfecho definitivo em vez de travar para sempre. A maioria dos sistemas de CI permite configurar timeouts no nível de job e de step.
Causas comuns
- Um deadlock ou loop infinito que nunca termina (determinístico).
- Um teste esperando por um evento que nunca dispara (muitas vezes uma race condition).
- Uma chamada de rede travando porque um upstream está lento ou inacessível (muitas vezes transitório).
- Um step genuinamente lento cujo limite está simplesmente baixo demais.
Exit codes de timeout
O timeout do GNU retorna 124 quando um comando excede seu limite. Provedores de CI podem, em vez disso, reportar o job como cancelado ou com timeout. De um jeito ou de outro, o sinal é o mesmo: o trabalho não terminou dentro da janela alocada.
Timeouts transitórios vs determinísticos
Um timeout é determinístico se o step sempre excede o limite (limite apertado demais, deadlock real) e transitório se ele só às vezes excede, geralmente porque estava esperando por uma rede lenta ou uma dependência momentaneamente sobrecarregada. Um retry ajuda no caso transitório e desperdiça tempo no determinístico.
A perspectiva da Latchkey
Quando um timeout remonta a uma causa transitória que a Latchkey consegue reconhecer, como uma chamada de rede travada contra um registry momentaneamente inacessível, o managed runner com autocorreção pode fazer retry para que uma instabilidade isolada não faça seu build falhar. Timeouts de deadlocks genuínos continuam sendo seus para corrigir.
Principais conclusões
- Um timeout de CI cancela um trabalho que excede seu limite configurado.
- Timeouts protegem a capacidade compartilhada e limitam gastos desperdiçados.
- O timeout do GNU sai com 124; provedores podem reportar um cancelamento.
- Um timeout pode ser transitório (rede lenta) ou determinístico (deadlock).