Bitriseのキャッシュと戯れる機会があったので、その過程でわかったことをまとめておきます。わかったことと言っても全部公式ドキュメントを探せば書いてある内容なのですが、一箇所にまとまっていると便利なので。

基本的な使い方

Bitriseでは、ユーザが指定したディレクトリをtarにしてS3にアップロードすることでキャッシュの仕組みが実現されています。これを利用するために、デフォルトで組み込まれている以下のステップを使います。

Cache:Pull: キャッシュを取得
Cache:Push: キャッシュを保存

workflowの中でははじめの方にCache:Pull、終わりの方にCache:Pushを設定しておくことで、workflowの前回実行時にpushされたキャッシュをpullして使うことができます。具体的には、npmパッケージのキャッシュをしたい場合は npm installの前にCache:Pullを、後にCache:Pushを入れておけばOKですね。

キャッシュするパスの指定方法として、自分で書くパターンと組み込みのステップがよしなにやってくれるパターンの２つがあります。

自分で書くパターンでは、Cache:Pushステップの設定画面のCache pathsのフォームに、例えば

./node_modules

のようにキャッシュしたいパスを書きます。ここに書かれたパスはCache:Pushで保存され、次回workflow実行時のCache:Pullで同じ場所に展開されます。

組み込みのステップがやってくれるパターンには、例えば Cocoapods Install があり、この場合は単純にCache:PullとCache:Pushの間にCocoapods Installのステップを入れれば、明示的にキャッシュの設定を書くことなく自動でキャッシュの更新・取得をしてくれます。

workflowを書く際には、自分が使いたいステップがキャッシュに対応しているか確認し、対応していればステップにお任せし、対応していなければCache:Pushに自分で設定を書くのが良いでしょう。

知っておいた方が良いこと

Bitriseのキャッシュはちょっと癖がある印象で、色々と試す前に最初から知っておけたらよかったと思った点がいくつかありました。

キャッシュがない場合はデフォルトブランチのキャッシュが使われる

Bitriseのキャッシュはブランチに紐づいています。そのため、ブランチAで取得するキャッシュは基本的にはそれ以前にブランチAで保存されたものになります。
例外として、過去に保存されたキャッシュが存在しないブランチでは、デフォルトブランチのキャッシュが使われます。例えば、ローカルで作成したブランチをpushしてPRを作成する場合、そのブランチのキャッシュは確実に存在しないためデフォルトブランチのキャッシュが参照されることになります。そのため、PRのCIを速くするためには、デフォルトブランチの方でPRで使われそうなキャッシュを作っておく必要があるということになります。ちなみに、個人的にはPRビルドではデフォルトブランチよりもベースブランチのキャッシュを優先して利用した方が良さそうと思い、検索してみるとそういう声も上がっているのですが現状では対応されていないようです。
BitriseのデフォルトブランチはSettingsから変更できるので、キャッシュのことを考慮してデフォルトブランチを決めるのもありかもしれません。

PRビルドではキャッシュはpushされない

デフォルトの設定ではPRビルドではキャッシュはpushされません。そのため、PRを出してCIが完了してからちょっと変更を加えようと思ってpushしたときでも、１回目のCIで保存されたキャッシュが使えて速くCIが終わるみたいなことはありません。この挙動については、bitrise.ymlの run_if を上書きすることでPRでもpushするように変更することはできますが、推奨されてはいないようです。

参考: https://discuss.bitrise.io/t/cache-push-is-not-working-since-run-if-expression-is-false-which-should-not-be-false/3731

保存されているキャッシュはwebから手動で削除/ダウンロードできる

Settings -> Manage Build Cachesからブランチごとにキャッシュの削除やダウンロードができて、トラブル時やデバッグ時に便利です。

リンク集

公式ドキュメントが一番わかりやすいです。