依存関係のキャッシュによるビルド高速化

CI にかかる時間の大部分は、実行のたびに同じ依存関係をダウンロードしてインストールすることに費やされます。キャッシュを使うと実行間で依存関係を保存できるため、後続のビルドで処理を再利用でき、パイプラインの時間を大幅に短縮できることがあります。

GitHub にはactions/cacheが用意されています。キャッシュするパスと、キャッシュエントリを識別するキーを指定します。ヒットするとパスが復元され、ヒットしなければジョブの終了後に保存されます。

キーは、キャッシュする内容が変わるときだけ変更されるようにします。ロックファイルのハッシュを使うのが理想的です。新しいロックファイルは新しい依存関係を意味するため、新しいキャッシュエントリが作成されます。

restore-keysはフォールバック用のプレフィックスを提供します。完全一致するキーが見つからない場合、アクションはキーがそのプレフィックスで始まる最新のキャッシュを復元し、部分的に準備済みの状態から開始できます。

キーが完全一致するとキャッシュヒットとなり、パスが復元されます。キャッシュミスの場合、ジョブは通常どおり実行され、終了時にプライマリキーを使ってキャッシュが保存されるため、次回から利用できます。

言語のセットアップアクションにはキャッシュ機能が組み込まれています。Node では、cache: npmを指定したsetup-nodeが依存関係のキャッシュを処理するため、個別のキャッシュステップは必要ありません。

可能な場合は、インストール済みのnode_modulesではなく、パッケージマネージャーのダウンロードディレクトリをキャッシュします。ダウンロードキャッシュは移植性があり、インストールステップで整合性の検証も行われるためです。

• Node: ~/.npm
• Python: pip キャッシュ
• Java: ~/.m2または Gradle キャッシュ

キャッシュのスコープはブランチごとに設定されます（デフォルトブランチへのフォールバックあり）。また、リポジトリごとにサイズ制限があります。使用されていないキャッシュは時間の経過とともに削除されるため、適切に入れ替わるキーを設計してください。

キーが一度も変わらないと、古い依存関係が使われる可能性があります。キーは必ずロックファイルのハッシュに関連付け、更新時にキャッシュが自動的に無効になるようにしてください。

OS やバージョンをまたぐマトリックスビルドでは、キーにrunner.osとバージョンを含めます。これにより各バリエーションに適切なキャッシュが割り当てられ、キャッシュ同士が衝突するのを防げます。

キャッシュ導入前後のジョブの実行時間を比較し、ログのキャッシュヒットインジケーターを確認します。ヒット率が継続的に低い場合は、キーが頻繁に変わりすぎている可能性があります。

依存関係のキャッシュについての理解度を確認します。

依存関係のキャッシュによって CI を高速化しました。ロックファイルのハッシュを使ったキーとrestore-keysのフォールバックを設定したactions/cacheアクション、セットアップアクションの組み込みキャッシュ、キャッシュ対象の選択、マトリックスのキーへの OS とバージョンの追加、そしてキーをロックファイルに関連付けて古いキャッシュを避ける方法を学びました。