O Que É Cache de Dependências no CI?

O cache de dependências salva os pacotes que seu build baixa para que a próxima execução os reutilize em vez de buscar tudo no registry de novo.

A maioria dos jobs de CI começa instalando dependências - pacotes npm, wheels de Python, jars do Maven. Fazer isso do zero em cada execução é lento e desperdiça recursos, porque as dependências raramente mudam entre commits. O cache de dependências as armazena após uma execução e as restaura no início da próxima.

O problema que ele resolve

Um runner de CI novo tem um diretório de pacotes vazio. Sem cache, cada job re-baixa (e frequentemente recompila) as mesmas dependências, somando minutos e carga no registry a cada execução. Em um repositório movimentado esse custo se repete centenas de vezes por dia.

Como funciona

• Após a instalação, o diretório de pacotes (por exemplo ~/.npm ou node_modules) é enviado para o armazenamento de cache sob uma key.
• Na próxima execução, o job procura essa key e restaura o diretório antes de instalar.
• Se a key corresponder, a instalação vira um passo quase instantâneo de "already satisfied".

A cache key é tudo

Uma boa key é derivada do hash do lockfile, então ela muda apenas quando as dependências mudam. Exemplo: node-${{ hashFiles('package-lock.json') }}. Uma key ampla demais serve pacotes obsoletos; uma key restrita demais nunca acerta.

Um pequeno exemplo

No GitHub Actions você poderia fazer cache de ~/.npm com key: npm-${{ hashFiles('package-lock.json') }} e uma restore-key de npm-. Quando o lockfile não muda a key exata acerta; quando ele muda, o fallback restaura o cache anterior mais próximo, então só o diff é baixado.

O que fazer cache (e o que não)

Faça cache do package store ou dos módulos instalados, não do seu código-fonte ou da saída do build (esses têm caches próprios). Evite fazer cache de qualquer coisa secreta ou específica da máquina, e prefira fazer cache do download cache em vez de binários instalados quando o passo de instalação é barato mas o download é lento.

Uma nota da Latchkey

Nos runners gerenciados da Latchkey o cache de dependências é restaurado por um caminho local rápido na mesma região em vez da internet pública, então os acertos de cache chegam em segundos mesmo para árvores de pacotes grandes.

Principais conclusões

• O cache de dependências reutiliza pacotes baixados entre execuções de CI.
• A cache key deve ser derivada do lockfile para invalidar corretamente.
• Faça cache do package store, nunca de secrets ou do código-fonte.

Guias relacionados