Cache de dependências (Fast Cache)

O Latchkey Fast Cache salva e restaura caches de dependências em uma única requisição de streaming, com armazenamento na mesma região do seu runner e configuração zero.

O Latchkey Fast Cache (latchkey-dev/cache-action@v1) é uma GitHub Action leve para salvar e restaurar caches de dependências (node_modules, registros de pacotes, artefatos de build) em runners gerenciados Latchkey. Runs repetidos pulam instalações que seu pipeline já fez.

Por que é rápido#

Os dados do cache trafegam em uma única requisição HTTP de streaming em vez do padrão serial de chunks que o actions/cache@v4 usa: sem round trips por chunk, sem arquivos temporários.
Compressão e descompressão são multi-thread (zstd), e uploads e downloads rodam como transferências paralelas.
O armazenamento fica na mesma região do seu runner, então os bytes nunca viajam longe.
Cada save e restore imprime seu tempo no log do job, então você pode medir a diferença nos seus próprios builds.

Adicione a um workflow#

Adicione dois passos: um com action: restore e outro com action: save. Cada um recebe um key e uma ou mais entradas path (separadas por quebra de linha ou espaço; ~ é suportado). O passo de restore expõe uma saída cache-hit para que você possa pular passos de instalação quando o cache é encontrado.

.github/workflows/ci.yml

jobs:
  build:
    runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v4

      - name: Restore dependencies
        id: cache
        uses: latchkey-dev/cache-action@v1
        with:
          action: restore
          key: deps-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
          path: node_modules

      - name: Install dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: npm ci

      - name: Save dependencies
        uses: latchkey-dev/cache-action@v1
        with:
          action: save
          key: deps-${{ runner.os }}-${{ hashFiles('package-lock.json') }}
          path: node_modules

Migrando do actions/cache#

actions/cache@v4

Transferências serial em chunks com round trips por chunk
Funciona em qualquer runner
Entradas: path, key, restore-keys

latchkey-dev/cache-action@v1

Uma requisição de streaming por save ou restore
Armazenamento pré-provisionado, na mesma região do runner
As mesmas entradas continuam funcionando: migrar é uma mudança de uma linha

Padrões seguros#

Uma falha de restore nunca faz o job falhar: você recebe um aviso, cache-hit fica como false e o run continua.
O save é pulado automaticamente quando a key já existe, então caches idênticos nunca são reenviados.
Caches são isolados por organização e versionados automaticamente por sistema operacional; codifique isolamentos mais finos (como versões de OS) na sua chave de cache.

O que você vê nos logs do job#

Linha de log	O que ela indica
`Cache restored in {N}ms`	O restore terminou, e quanto tempo levou
`Cache saved in {N}ms`	O save terminou, e quanto tempo levou
`Cache miss`	Não existia cache para a key; `cache-hit` é `false` e o job continua
`Cache already exists for key=..., skipping save`	O save foi pulado porque uma key idêntica já está armazenada

Cache que você não precisa procurar#

O AI Scan detecta de quais caches seu projeto precisa e os lista na configuração de runner proposta, e os PRs de otimização por IA podem adicionar ou substituir passos de cache para você, prontos para merge. Times que nunca ajustam cache na mão mesmo assim o obtêm.

Para o ofício mais amplo - reduzir tempo de instalação, dividir suítes lentas, paralelizar - a biblioteca Learn tem um hub de otimização de CI prático com guias que você pode aplicar em qualquer runner.