O que é CI efêmero? Por que runners novos importam
CI efêmero dá a cada job uma máquina limpa e de uso único que é descartada quando o job termina - então nenhuma execução pode contaminar a próxima.
Um runner efêmero é criado para um único job e destruído depois, sem deixar estado para trás. É o oposto de um runner de longa duração que acumula arquivos, caches e efeitos colaterais entre execuções.
O que "efêmero" significa
Um ambiente novo é provisionado para um único job, executa esse job e é destruído. Nada que ele escreveu - arquivos temporários, ferramentas instaladas, processos vazados - sobrevive para afetar o próximo job. Toda execução começa da mesma linha de base conhecida.
Por que importa
- Sem vazamento de estado: um job não pode envenenar o ambiente de outro.
- Reprodutibilidade: um build verde significa que passa de um estado limpo, não por causa de estado remanescente.
- Segurança: secrets e dados de checkout não ficam em uma máquina compartilhada.
- Depuração mais fácil: falhas não são "funciona depois que limpei o runner".
O trade-off
Uma máquina limpa não tem nada em cache, então runners efêmeros pagam um imposto de cold start e de instalação de dependências a cada job. A mitigação padrão é um cache externo (dependências, camadas de Docker) que restaura as partes caras sem compartilhar estado sujo.
Efêmero vs persistente
Runners persistentes são mais rápidos porque o estado é reaproveitado, mas esse mesmo estado causa flakiness do tipo "só passa no runner #3". A maioria das equipes escolhe efêmero pela corretude e adiciona cache para recuperar a velocidade.
Principais conclusões
- Efêmero = uma máquina nova e de uso único por job, destruída depois.
- Elimina vazamento de estado entre execuções e melhora reprodutibilidade e segurança.
- O custo são cold starts e instalações repetidas de dependências.
- O cache restaura a velocidade sem reintroduzir estado compartilhado sujo.