# CI Caching Explicado: Acelere Pipelines Sem Quebrá-los

> Como o CI caching funciona, o que fazer cache (dependências, build outputs, layers Docker), como cache keys e restore keys funcionam, e erros comuns de caching.

Source: https://latchkey.dev/pt/learn/ci-cd-concepts/ci-caching-explained  
Updated: 2026-06-25

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.

```GitHub Actions cache config
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.

## FAQ

### What is CI caching Explained: speed up Pipelines without breaking them?

Most CI time is spent re-doing work that has not changed: downloading the same dependencies, rebuilding the same layers. Caching stores those outputs and restores them on the next run. Done right it cuts minutes off every job; done wrong it serves stale data or silently never hits.

### Cache keys and restore keys?

A cache key should change exactly when the cached content should change - typically a hash of your lockfile. Restore keys provide a fallback prefix so a near-miss still restores a useful older cache instead of nothing. Too-broad a key serves stale data; too-narrow a key never hits.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt