CI Caching Explicado: Acelere Pipelines Sem Quebrá-los
Caching é a forma de maior alavancagem para acelerar o CI - e uma fonte comum de falhas sutis e difíceis de depurar quando as keys estão erradas.
A maior parte do tempo de CI é gasta refazendo trabalho que não mudou: baixando as mesmas dependências, reconstruindo as mesmas layers. O caching armazena esses outputs e os restaura na próxima run. Feito corretamente, ele corta minutos de cada job; feito errado, ele serve dados obsoletos ou silenciosamente nunca dá hit.
O que vale a pena fazer cache
- Diretórios de dependências (node_modules, ~/.m2, ~/.cargo, pip wheels).
- Build outputs e caches de compilador (builds incrementais, ccache).
- Layers Docker via um layer cache respaldado por registry.
Cache keys e restore keys
Uma cache key deve mudar exatamente quando o conteúdo em cache deve mudar - tipicamente um hash do seu lockfile. Restore keys fornecem um prefixo de fallback para que um near-miss ainda restaure um cache antigo útil em vez de nada. Uma key ampla demais serve dados obsoletos; uma key restrita demais nunca dá hit.
key: deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
deps-Erros comuns
- Usar como key algo que sempre muda (um commit SHA) → taxa de hit de 0%.
- Usar como key algo estável demais → dependências obsoletas servidas para sempre.
- Fazer cache de um diretório que é reconstruído de qualquer forma, então o cache nunca ajuda.
- Ignorar os limites de tamanho do cache e silenciosamente despejar caches quentes.
Principais conclusões
- Faça cache do trabalho caro e que raramente muda: dependências, build outputs, layers Docker.
- Use como key um hash do lockfile; use restore-keys como prefixo de fallback.
- Uma key errada ou serve dados obsoletos ou nunca dá hit - ambos parecem "o caching não faz nada".