ビルドフィンガープリントとは何か？入力と出力を識別する

ビルドフィンガープリントとは、入力からビルドを一意に識別するハッシュで、システムが同一の作業を認識して結果を再利用できるようにします。

ビルドシステムは、ファイルの再コンパイルをスキップできる、あるいはキャッシュされたレイヤーを再利用できると、どうやって知るのでしょうか。入力をフィンガープリント化するのです。ビルドstepに供給されるソース、依存関係、configにハッシュをかけることで、フィンガープリントを生成します。同じフィンガープリントが再び現れたら、入力は同一なので出力も同一のはずであり、作業はスキップできます。

フィンガープリントに何が入るか

ソースファイルの内容。
依存関係のバージョンとlockfile。
ビルドフラグと構成。
依存するupstream stepのフィンガープリント。

なぜフィンガープリントがキャッシュを可能にするか

フィンガープリントをキーとするキャッシュは安全です。cache hitは、まさに同じ入力が以前に出力を生成したことを意味するので、再利用は正しいのです。どれか入力を変えればフィンガープリントが変わり、rebuildが強制されます。だからこそ、良いcache keyは本質的にフィンガープリントなのです。

簡単な例

依存関係のキャッシュは、deps-${hashFiles("package-lock.json")} のようにlockfileのハッシュをキーとすることがよくあります。lockfileが変更されていなければ、フィンガープリントが一致し、キャッシュされた node_modules が再インストールの代わりに復元されます。

フィンガープリントと正確性

フィンガープリントは、出力に影響するすべての入力をカバーしなければなりません。1つ（env var、コンパイラのバージョン）を見落とすと、偽のcache hitが得られます。古い結果を再利用してしまうのです。含めすぎると不要なcache missが得られます。入力を正しく捉えることがすべてです。

高速なパイプラインでのフィンガープリント

フィンガープリントベースのキャッシュは変更されていない作業をスキップし、これは利用可能な最大のCI高速化の1つです。マネージドランナー（Latchkey）はこの方式でキーづけされたウォームキャッシュを維持するので、変更されていない依存関係やレイヤーはrebuildではなく即座に復元されます。

重要なポイント

ビルドフィンガープリントは、作業を識別するビルドの入力のハッシュです。
一致するフィンガープリントは入力が同一であることを意味し、出力を再利用できます。
正しいフィンガープリントは、結果に影響するすべての入力をカバーしなければなりません。