Skip to content
Latchkey

O Que É um Build Fingerprint? Identificando Entradas e Saídas

Um build fingerprint é um hash que identifica unicamente um build a partir de suas entradas, para que o sistema reconheça trabalho idêntico e reutilize o resultado.

Como um sistema de build sabe que pode pular a recompilação de um arquivo ou reutilizar uma layer em cache? Ele faz o fingerprint das entradas. Ao aplicar hash sobre o source, as dependências e a config que alimentam um step de build, ele produz um fingerprint. Se o mesmo fingerprint aparecer novamente, as entradas são idênticas, então a saída também deve ser, e o trabalho pode ser pulado.

O que entra em um fingerprint

  • Conteúdo dos arquivos de source.
  • Versões de dependências e lockfiles.
  • Flags de build e configuração.
  • O fingerprint dos steps upstream dos quais ele depende.

Por que fingerprints permitem cache

Um cache indexado por fingerprint é seguro: um cache hit significa que exatamente as mesmas entradas produziram uma saída antes, então reutilizá-la é correto. Mude qualquer entrada e o fingerprint muda, forçando um rebuild. É por isso que uma boa cache key é essencialmente um fingerprint.

Um exemplo rápido

Um cache de dependências frequentemente é indexado por um hash do lockfile, como deps-${hashFiles("package-lock.json")}. Se o lockfile está inalterado, o fingerprint corresponde e o node_modules em cache é restaurado em vez de reinstalado.

Fingerprints e correção

Um fingerprint deve cobrir cada entrada que afeta a saída. Perca uma (uma env var, uma versão de compilador) e você obtém um falso cache hit: reutilizar um resultado obsoleto. Inclua demais e você obtém cache misses desnecessários. Acertar as entradas é todo o jogo.

Fingerprints em pipelines rápidos

O cache baseado em fingerprint pula trabalho que não mudou, o que é um dos maiores ganhos de velocidade de CI disponíveis. Runners gerenciados (Latchkey) mantêm caches aquecidos indexados dessa forma, então dependências e layers inalteradas são restauradas instantaneamente em vez de reconstruídas.

Principais conclusões

  • Um build fingerprint é um hash das entradas de um build que identifica o trabalho.
  • Um fingerprint correspondente significa entradas idênticas, então a saída pode ser reutilizada.
  • Um fingerprint correto deve cobrir cada entrada que afeta o resultado.

Guias relacionados