Actions&Terraform

GitHubActionsのワークフローでファイルのハッシュ値を取得する

Actions で実行している Kotlin や Java のビルドタスク。

ビルドが実行される度に gradle の依存ライブラリがダウンロードされるのはどうかと思い、キャッシュすることにしました。

gradle 関連のファイルが変更されたときだけ取得し直せばいいので、無駄なトラフィックや時間は省けた方が効率的ですよね。

今回はキャッシュキーに、関連ファイルのハッシュ値を使うことにしましたので、Actions のジョブ内でのハッシュ値の取得方法を紹介していきます。

ファイルのハッシュ値を取得する

ベタにシェルでハッシュを取得してもいいのですが、Actions に hashFiles という関数が用意されているので、これを利用しましょう。

「path パターンにマッチするファイル群から単一のハッシュを返します」とのことなので、変更確認対象のファイルが複数あっても簡単に定義でき便利です。

例えば、リポジトリ直下の gradle ファイルと、配下のディレクトリの build.gradle を対象にしたい場合は以下の通り。

${{ hashFiles(‘*.gradle’, ‘**/build.gradle’) }}

NodeJS であれば「package-lock.json」、PHP なら「composer.lock」など、言語や用途に合わせてキャッシュできるものはたくさんありそうです。

gradleパッケージのキャッシュ

では、Actions のジョブにキャッシュのステップを追加してみます。

公式のサンプルでは、キャッシュキーに「os.runner」が指定されていますが、ubuntu-latest でもセルフホストランナーでも「Linux」としか入ってこないので、あまり指定する意味はないのかなと思っています。

リストアキーについては、プレフィックスを指定しておくと別ブランチでも利用できるので、キャッシュキーと完全一致させるよりは効率的ですね。
(一致するキーのものがなくても、プレフィックスが一致した最新のキャッシュをリストアしてくれる)

ここは用途に合わせてといったところでしょうか。

ちなみにキャッシュ容量については以下の説明がされています。

・リポジトリごとに 5GB まで
・5GB を超える場合は参照されたのが一番古いキャッシュから削除される
・1 週間以内にアクセスがないキャッシュも削除される

まとめ

Actions のキャッシュ機能を利用してみました。

ジョブの実行時間が長い時は、ボトルネックになっている部分が高速化できないか検討してみたいですね。

一度、じっくりと Actions のリファレンスをまとめる時間を作りたいところです。