導入:CIの待ち時間を劇的に減らす「キャッシュ」の最適化
GitHub Actionsを利用していると、npm installやpip installなどの依存関係のインストールに時間がかかり、CIの実行時間が長引くことはありませんか?この課題を解決するのがキャッシュ機能です。しかし、キャッシュキーの設定を誤ると、依存関係が更新されたのに古いキャッシュが読み込まれたり、逆に常に再インストールが走ってキャッシュの恩恵を受けられなかったりします。今回は、hashFiles関数を用いて「必要な時だけ」キャッシュを更新する、最も効率的なCIパイプラインの構築術を解説します。
基礎知識:キャッシュキーとhashFilesの役割
GitHub Actionsのキャッシュ機能は、指定したキー(Key)が一致する場合にのみ、過去の保存データを取り出します。
Cache Invalidation(キャッシュ無効化)とは、ソースコードの変化に合わせてキャッシュを強制的に作り直す仕組みのことです。ここで重要になるのがhashFiles関数です。これは引数に指定したファイル(package-lock.json等)の内容を読み取り、そのハッシュ値を生成します。ファイルの内容が1文字でも変わればハッシュ値が変わるため、これをキーに含めることで、依存関係の変更を自動検知してキャッシュを再構築できるようになります。
実装:最適なキャッシュ戦略
キャッシュキーを設計する際は、「OS」「パッケージマネージャー」「ハッシュ値」の3要素を組み合わせるのが基本です。
1. OSの指定: OSによってインストールされるバイナリが異なるため、分離する必要があります。
2. 固定値: キャッシュをクリアしたい時に手動で変更するための接頭辞を含めます。
3. ハッシュ値: hashFiles関数を使用して、ロックファイルをキーに組み込みます。
サンプルプログラム:Node.jsプロジェクトでの最適化例
以下は、`.github/workflows/ci.yml` に記述する典型的な設定例です。
キャッシュを利用したNode.jsのビルド設定
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: ノード環境のセットアップ
- name: キャッシュの設定
- name: 依存関係のインストール
応用・注意点:現場で陥りやすい罠
現場でよくあるミスとして、npm install と npm ci の混同があります。CI環境では必ず `npm ci` を使用してください。`npm install` はロックファイルが未更新でもキャッシュを上書きしようとしますが、`npm ci` はロックファイルの内容を厳密に守るため、キャッシュとの相性が非常に良いです。
また、キャッシュサイズの制限にも注意が必要です。GitHub Actionsのキャッシュにはリポジトリあたり10GBの制限があります。古すぎて参照されなくなったキャッシュは自動的に削除されますが、特定の環境で巨大なキャッシュを生成し続けるとCIが不安定になることがあります。もしキャッシュが巨大化しすぎる場合は、不要なファイルを除外する `path` の指定を工夫するか、定期的にキャッシュを整理する運用を検討しましょう。適切なハッシュ管理を行うだけで、日々の開発体験は確実に向上します。

コメント