GitHub Actionsで公式のアクションを利用するとき、依存パッケージを適切にキャッシュすることが大切です。
setup-node・setup-python・setup-javaにはcacheオプションがあり、指定したパッケージマネージャーに応じてキャッシュしてくれます。
setup-goの場合はcacheオプションはブール値ですが、デフォルトが有効になっているのでこれを指定しなくてもキャッシュしてくれます。
これらのアクションは、リポジトリの依存管理ファイルの内容をキャッシュのキーとして保存します。
例えば、setup-nodeでcache: npmを指定するとリポジトリルートのpackage-lock.jsonファイルの内容を元にキャッシュのキーを計算します。
しかし、モノレポ構成のリポジトリでは依存管理ファイルが各パッケージのディレクトリに配置されているため、ルートのファイルしか見ないのは不十分です。
このようなケースで役に立つのがcache-dependency-pathオプションです。
- uses: actions/setup-node@v4 with: node-version-file: .node-version cache: npm cache-dependency-path: subdir/package-lock.json
setup-go, setup-pythonにも同じオプションがあり、モノレポ構成でのキャッシュの挙動を制御できるようになっています。
さて、タイトルのsetup-javaの話です。
リポジトリルートの依存管理ファイルしか見ないsetup-nodeやsetup-goとは異なり、setup-javaはリポジトリ全体から検索してキャッシュキーを計算します。
これではキャッシュが複数のプロジェクト間で共有されてしまう上に、一つのプロジェクトの依存の変更が全てのプロジェクトのキャッシュに影響してしまいます。
しかも、cache-dependency-pathオプションがsetup-javaにはありませんでした。
仕事で使う上でだいぶ困っていたのと、他の公式アクションには揃っているオプションがsetup-javaにだけない理由はないと感じたので、サクッと実装してみました。 今年の六月のことです。 github.com しばらく放置されてダメかと思っていましたが、二週間前にようやくレビューしていただき、先日ようやくマージされました。 v4としてリリースされています。
使い方は、他のactionのcache-dependency-pathと同じです。
サブプロジェクトのGradleファイルを指定するとその内容を元にキャッシュキーが計算されます。
- uses: actions/checkout@v4 - uses: actions/setup-java@v4 with: distribution: corretto java-version: '17' cache: gradle cache-dependency-path: | sub-project/*.gradle* sub-project/**/gradle-wrapper.properties
今回、公式のactionに初めてコントリビュートできました。 TypeScriptで書かれていてコントリビュートしやすいですし、actionのE2Eのやり方なども参考になりました。 個人的にはまだ大きなactionを実装したことがないので、何か作ってみたいと思いました。
