GitHub Actionsでnode_modulesをキャッシュ化しようとしたところ、keyにgithub.shaを使ってしまっていたため、全く機能していなかった原因とその対処法について解説します。
さらっとおさらい
GitHub Actionsとは？
ChatGPTくんに聞いてみました。
GitHub Actionsは、GitHubが提供するCI/CD（継続的インテグレーション/継続的デリバリー）ツールです。これにより、リポジトリ内のコードを自動的にビルド、テスト、デプロイするプロセスを簡単に設定・実行できます。GitHub Actionsは、イベント駆動型であり、プッシュ、プルリクエスト、リリースなどの特定のアクションに応じてワークフローをトリガーします。これにより、開発者は手作業の繰り返し作業を自動化し、コードの品質とデリバリースピードを向上させることができます。
GitHubでのイベントに反応して色々自動化できる、便利なものだよ〜ってことです。
actions/cacheって？
actions/cacheとは、依存関係やビルド出力をキャッシュ保存してくれるアクションで、今回で言うとyarn installで作成されるnode_modulesを、初回以降はキャッシュから生成してくれるようになります。
バージョンによって実行する環境が異なり、v3だとNode16、v4だとNode20の環境で実行されます。
私の開発環境ではNode.18を利用しているため、v3で実行しています。
ハマった部分
さて、本題ですが、今回僕の犯したミスは2つあります。
- keyにgithub.shaを利用していた
- restore-keysを設定していなかった
github.shaとはコミットごとに異なる値です。これをkeyとして設定してしまうと、ビルド毎に常に新しいキーが扱われるため、新しいキャッシュが常に作成され、全く機能していませんでしｔ。あ
さらに、restore-keysの設定をしていなかったため、部分一致でキャッシュを探すことができず、キャッシュキー一切有効活用されていませんでした。
# やらかしたコード
- name: Cache node_modules
uses: actions/cache@v3
with:
path: ./node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-json.lock') }}-${{ github.sha }}解決法
- github.shaをキャッシュキーに使用しない
- キャッシュヒットの可能性を高めるため、restore-keysを設定した
- name: Cache node_modules
uses: actions/cache@v3
with:
path: ./node_modules
key: ${{ runner.os }}-node-modules-${{ hashFiles('**/package-json.lock') }}
restore-keys:
${{ runner.os }}-node-modules-本当にこれだけで、問題が解決しました。意外と見落としがちなので注意が必要です。
まとめ
余談ですが、eslint等の静的解析のアクションを走らせる場合にはgithub.ref_nameを末尾につけることで、「同じブランチで作業する時には無駄なeslintを走らせないようにする」こともできます。
ただし、この場合にブランチ判定が入ってないキーをrestore-keysとして設定してしまうと「別ブランチで静的解析アクションが失敗した場合、そのキャッシュが保持されてしまう」ことがあります。注意しましょう。
GitHub Actionsでのキャッシュの効果を最大化するためには、適切なキャッシュキーの設定が不可欠です。特に、github.shaのようなコミットごとに変わるキーを避けることが重要です。私の経験が皆さんの参考になれば幸いです。キャッシュの最適化によってビルド時間の短縮を目指しましょう！
以上、私の経験を元にしたGitHub Actionsのキャッシュ設定に関する注意点でした。ぜひ試してみてください。
