Cache de camadas Docker

O Latchkey Docker Cache Build envolve o docker buildx com cache de camadas apoiado em registry, então builds repetidos de imagens reaproveitam cada camada inalterada entre runners efêmeros.

Cada runner Latchkey é uma instância nova e isolada. Isso é bom para segurança e ruim para o cache local de camadas do Docker, que desaparece junto com o runner. O Latchkey Docker Cache Build resolve isso com um cache de camadas armazenado em um registry de containers privado gerenciado pela Latchkey para sua organização: camadas correspondentes de builds anteriores são reaproveitadas, e o cache atualizado é gravado de volta para o próximo run.

Adicione ao seu workflow#

.github/workflows/build.yml

jobs:
  build:
    runs-on: latchkey-medium
    steps:
      - uses: actions/checkout@v4
      - uses: latchkey-dev/docker-cache-action@v1
        with:
          context: .
          tags: myapp:latest
          push: true

Essa é a integração inteira: você fornece as entradas que daria a qualquer build Docker, e a Latchkey cuida do registry, das credenciais e da conexão do cache. Por padrão a action usa cache-mode: max, que faz cache de todas as camadas, incluindo camadas intermediárias de builds multi-stage. Builds de plataforma única com push: false carregam a imagem construída no daemon Docker local do runner.

Entradas e saídas#

Entrada	Padrão	O que faz
`tags`	obrigatório	Tags para a imagem construída
`context`	`.`	Caminho do contexto de build
`dockerfile`	`Dockerfile`	Caminho para o Dockerfile
`push`	`false`	Faz push da imagem construída
`build-args`	nenhum	Argumentos de build; os valores são mascarados nos logs pois podem conter segredos
`target`	nenhum	Stage alvo para builds multi-stage
`platforms`	nenhum	Plataformas alvo para o build
`cache-mode`	`max`	Escopo do cache: `min` ou `max` (max faz cache de todas as camadas, incluindo camadas intermediárias de multi-stage)
`cache-tag`	`cache`	Tag do registry usada para o cache de camadas
`extra-cache-from` / `extra-cache-to`	nenhum	Fontes e destinos de cache adicionais passados para o build

Saída	O que ela indica
`cache-configured`	`true` quando o cache de camadas via registry esteve ativo para o build, `false` caso contrário
`image-digest`	Digest da imagem construída

Seguro em qualquer runner#

Em runners que não são Latchkey (por exemplo, hospedados no GitHub), a action detecta que o registry de cache não está disponível e faz o build normalmente, sem flags de cache. Um único arquivo de workflow permanece portável entre tipos de runner.
No primeiro build de um repositório o cache está vazio; se um build com cache falhar nesse primeiro run, a action automaticamente refaz sem cache. Os primeiros runs nunca quebram por causa do cache.
Os valores de build-arg são mascarados nos logs, então segredos passados como build args não vazam para a saída do job.
Caches são isolados por organização.