自作アプリのビルドにGitHub Actionsを使っています。Electron製アプリのmacOS・Windows・Linuxのそれぞれのビルドができるので、とても助かっています。
プライベートリポジトリのビルドなので、料金が掛かります。Linuxは1分あたり0.008ドルと安価なのですが、Windowsは0.016ドル(2倍)、macOSは0.08ドル(10倍)という価格になっています。ビルドには約10分掛かるので、1回あたり(0.008+0.016+0.08)*10=1.04ドルの費用が掛かります。開発版をナイトリービルドすると月に約30ドル掛かることになります。
なるべく費用を抑えられないかとキャッシュ機能を導入してみたのですが、微妙な効果となり、利用は見送ることにしました。この記事ではどう微妙だったのかを記載します。
キャッシュとは
GitHub Actionsの標準機能で、作成に処理時間やネットワークアクセスを要するファイルを再利用するために保存しておき、あとで再利用することでビルドを効率的にするためのものです。
キャッシュした内容
Electron製アプリなので、Nodeモジュールを多数使用しており、そのインストールに時間が掛かっていました。
macOS | Windows | Linux | |
yarn install | 1:18 | 2:42 | 1:07 |
この時間を削減すべく、node_modulesディレクトリをキャッシュ・・・しようとしたのですが、公式ドキュメントではYarnのキャッシュをキャッシュすることが推奨されていました。パッケージをネットワークから取得する時間が掛からなくなるので、処理時間の削減が期待できます。なぜnode_modulesではなくYarnキャッシュなのかは調べていませんが、公式推奨に従っておきました。
キャッシュ方法
公式ドキュメントからほぼコピペです。
- name: Get yarn cache directory path
id: yarn-cache-dir-path
run: echo "::set-output name=dir::$(yarn cache dir)"
- uses: actions/cache@v1
with:
path: ${{ steps.yarn-cache-dir-path.outputs.dir }}
key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
restore-keys: |
${{ runner.os }}-yarn-
ベンチマーク結果
キャッシュヒットミス時
macOS | Windows | Linux | |
Run actions/cache@v1 | 0:01 | 0:00 | 0:00 |
yarn install | 1:18 | 2:42 | 1:07 |
Post actions/cache@v1 | 3:53 | 0:36 | 0:33 |
合計 | 5:12 | 3:18 | 1:40 |
まずはキャッシュが存在しない、もしくは、キャッシュの展開が終わっていなかった場合です。後者について補足です。ベンチマークすべく2回連続で同じビルドを実行したところ、1回目で作成したキャッシュを2回目で見つけることができませんでした。そのまま丸1日放置して3回目の実行をしたところ、そちらではキャッシュが見つかりました。どうやらキャッシュがクラウド上に展開されるまで多少の時間が掛かるようなのです。
さて、処理時間ですが「Run actions/cache@v1」と「Post actions/cache@v1」が増えています。「Run actions/cache@v1」はキャッシュを取得する処理です。今回はキャッシュヒットミス時なので、すべてのOSで一瞬で終わってます。「Post actions/cache@v1」はキャッシュヒットミス時に、次回実行に備えて今回の処理結果をキャッシュする処理です。macOSの処理時間の長さが目立ちます。アクションのログを確認したところ、tarでディレクトリを単一ファイルにgzip圧縮していました。
/usr/bin/tar -cz -f /Users/runner/runners/hogehoge/cache.tgz -C /Users/runner/Library/Caches/Yarn/v6 .
キャッシュヒット時
macOS | Windows | Linux | |
Run actions/cache@v1 | 2:37 | 1:19 | 0:12 |
yarn install | 0:46 | 1:01 | 0:36 |
Post actions/cache@v1 | 0:02 | 0:04 | 0:01 |
合計 | 3:25 | 2:24 | 0:49 |
続いてキャッシュヒット時です。「Run actions/cache@v1」にそれなりに時間が掛かっています。tar+gzipの伸張を行っています。「Post actions/cache@v1」はキャッシュの更新は不要なので、一瞬で終わっています。
まとめ
macOS | Windows | Linux | |
キャッシュなし | 1:18 | 2:42 | 1:07 |
キャッシュヒットミス時 | 5:12 | 3:18 | 1:40 |
キャッシュヒット時 | 3:25 | 2:24 | 0:49 |
キャッシュヒット時でも、キャッシュなしの場合と同じぐらい(Windows・Linux)か、遅くなって(macOS)いますね。今回は採用を見送った方が良さそうです。
GitHub Actionsのキャッシュはtar+gzip形式で保存されるため、作成・利用のどちらのタイミングでもそれなりに処理時間が掛かってしまうようです。そのため「とりあえず有効にしておく」のではなく、しっかりベンチマークを行った上で、キャッシュすべきかどうか、見極める必要があることがわかりました。
おまけ
macOSだけ処理時間が長かった理由ですが、単純にキャッシュ対象サイズが大きかっただけでした。macOSの環境の性能が低いわけではありませんでした。tar+gzipの伸張にその分だけ時間が掛かる点は納得です。
macOS | Windows | Linux | |
キャッシュなし | 1,526,082,694 | 223,371,849 | 226,353,276 |