Gradle のリモートビルドキャッシュ

概要

Bitrise リモートビルドキャッシュを使用すると、ローカルビルドと CI ビルドの両方に Gradle ビルドキャッシュを利用できます。このソリューションは、Gradle タスクの出力をリモートサーバーにキャッシュします。ビルドを実行するとき、Gradle は出力がリモートキャッシュで利用可能なタスクを実行せず、代わりにキャッシュエントリをダウンロードします。

無料でお試しください

30 日間の無料トライアルを無料でご提供しています。お支払い情報を提供する必要もありません。トライアルは、Bitrise Build Cache を設定すると自動的に開始されます。

Bitrise Build Cacheを使い始めるにはここをクリックしてくださいBitrise アカウントをお持ちでない場合は、ビルドキャッシュの設定に進む前に、まずアカウントを作成するように求められます。

Gradle ビルドキャッシュ他のビルドによって生成された出力を再利用することで時間を節約できます。Bitrise ビルドキャッシュを使用すると、Bitrise と他の CI 環境の両方で CI ビルドに利用できます。

Gradle ビルドは、入力と出力を含む一連のタスクです。 Bitrise は、タスクの出力をパフォーマンスの高いリモートサーバーにキャッシュします。 Gradle ビルドを開始すると、Gradle は出力がリモートキャッシュにあるタスクの実行をスキップし、代わりにキャッシュエントリをダウンロードして再利用します。

依存関係のキャッシュとビルドのキャッシュ

ビルドキャッシュと依存関係キャッシュは別の概念です。ベストプラクティスは、ビルド時間を最小限に抑えるために両方を使用することです。続きを読む： Gradle 依存関係のキャッシュ。

キーベースの依存関係キャッシュを使用する

従来の依存関係キャッシュのステップをリモートビルドキャッシュと組み合わせて使用しないことをお勧めします。代わりに、ビルドキャッシュのみを組み合わせてください。キーベースの依存関係のキャッシュ。これは、従来の依存関係キャッシュがビルド間でビルド設定を引き継ぐときに発生する可能性のある予期せぬ結果を防ぐためです。

他の CI 環境での Gradle のリモートキャッシュの構成

Bitrise Build Cache では Bitrise CI を使用する必要はありません。他の CI/CD サービスを使用しても、リモートキャッシュを活用して Gradle のビルド時間を短縮できます。

これを行うには、ビルド中に Bitrise Build Cache CLI をダウンロードし、CLI を実行して Bitrise Build Cache を有効にするように CI 環境を構成する必要があります。

Bitrise でパーソナルアクセストークンを生成します。パーソナルアクセストークンの作成。

プロセス中に必要になるため、トークンの値をコピーします。
あなたの ワークスペース ID。これを行うには、ワークスペースのページに移動し、URL で ID を見つけます。
CI 構成で次の環境変数を設定します。
- BITRISE_BUILD_CACHE_AUTH_TOKEN: 値はパーソナルアクセストークンである必要があります。
- BITRISE_BUILD_CACHE_WORKSPACE_ID: 値は Bitrise Workspace スラグである必要があります。
高速化するステップの前に、次のスクリプトを CI 構成に追加します。

環境

高速化したい Gradle コマンドと同じ環境でスクリプトを実行してください。たとえば、ビルド全体で複数の Docker コンテナを使用する場合は、Bitrise Build Cache CLI が Gradle コマンドと同じ Docker コンテナで実行されていることを確認してください。
```
#!/usr/bin/env bash
set -euxo pipefail

# download Bitrise Build Cache CLI
curl -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b /tmp/bin -d

# run the CLI to enable Bitrise build cache for Gradle
/tmp/bin/bitrise-build-cache enable-for gradle
```

Gradle 実行理由診断ビルド

概要

Bitrise で Gradle 診断ビルドを実行して、Gradle タスク実行イベントの背後にある理由を調べることができます。これにより、リモートキャッシュのキャッシュミスを削減できます。

キャッシュヒット率は、キャッシュが受信したリクエストの数と比較して、キャッシュが正常に埋めることができたコンテンツリクエストの数を測定したものです。キャッシュミスの数が多いと、キャッシュを最大限に活用できないため、ビルドの速度が低下します。

Gradle タスクを実行すると、タスク入力の変更によってキャッシュミスが発生することがよくあります。Gradle の実行理由は、入力の変更が発生した理由を理解し、問題をデバッグするのに役立ちます。

読み続けると、Gradle タスクとそのキャッシュがどのように機能するかについての詳細を理解できます。

Bitriseで診断ビルドを設定する方法については、診断ビルド。

Gradle タスクとキャッシュ

Gradle ビルドシステムでは、アクションの基本単位はタスクです。タスクには、クラスのコンパイル、ユニットテストの実行、JAR の作成などがあります。各タスクには、ファイルや環境変数などの独自の入力と出力があります。

タスクは通常、各モジュールごとに設定可能な特定のビルドディレクトリに出力を生成します。このディレクトリの内容は、同じマシン上のビルド間で再利用されることがよくあります。そのため、Gradleは再利用できないタスクのみを実行することで時間を節約します。他のタスクでは、ビルドディレクトリからの出力が再利用され、タスクは UP-TO-DATE ラベル。このプロセスはGradleが増分ビルド。

増分ビルドと増分タスク実行

増分ビルドは増分タスク実行とは異なります。増分タスクについては、 Gradleの公式ドキュメント。

CI 環境での Gradle タスク

CI環境でGradleを実行する場合、ビルドディレクトリが空であるため、すべてのタスクは実行されるか、キャッシュから取得されます。実行後、Gradleはタスク入力に関するメタデータをプロジェクトキャッシュディレクトリGradle はこのメタデータを使用して増分ビルドを実行できるようにします。

たとえば、コンパイルタスクの場合、Gradleはソースファイルのチェックサムを保存し、チェックサムに基づいて変更されたファイルのみを再コンパイルします。Gradleがタスク入力をチェックする方法の詳細については、タスクの入力と出力に関する Gradle のドキュメントを読んでください。

メタデータが利用できない場合、Gradle はすべてのタスクを実行します。

キャッシュタスク

メタデータがタスクを実行する必要があることを示し、Bitriseビルドキャッシュが有効になっている場合、タスク入力とバージョンなどの特定のGradleプロパティがキャッシュキーにハッシュされます。リモートまたはローカルキャッシュのいずれかにキャッシュキーが一致する場合、タスクを完全に実行する必要はありません。その実行結果はキャッシュから読み込まれ、 FROM-CACHE 結果ラベル。

リモートキャッシュまたはローカルキャッシュにキャッシュキーが一致しない場合 (キャッシュミス)、タスクは完全に実行され、その出力はキャッシュに保存されます。

タスクに UP-TO-DATE ラベルの場合、その理由が記録され、Bitrise の呼び出し詳細のタスクの行に表示されます。考えられる理由のいくつかは次のとおりです。

メタデータが欠落している場合は、履歴はありませんが表示されます。
出力が欠落している場合は、出力...が削除されましたが表示されます。
タスクなし UP-DO-DATE 入力が以前に少なくとも 1 回キャッシュされている場合、ラベルは引き続きキャッシュされます。

診断ビルド

タスクの実行にどのような変更が影響しているかを把握するには、Gradle メタデータと以前のビルドからのビルド出力が必要です。これらを CI 環境で復元すると、ローカルの増分ビルドがシミュレートされ、キャッシュミスの原因となるビルド間の変更が表示されます。

これらのビルドは、Bitrise では診断ビルドと呼ばれます。

デバッグ目的のみ

診断ビルドでは頻繁に使用されるキーベースのキャッシュビルド時間が長くなります。これらはデバッグを目的としており、日常のワークフローの一部にすべきではありません。

キーベースのキャッシュのアーカイブ制限は 15 Gb です。アプリの出力がこの制限を超える場合は、独自の成果物ストレージソリューションを使用して、同じ原則で 2 つの個別のビルドを実行できます。

Gradle 診断ビルドをセットアップして実行するには:

次の CI 構成を作成します。
- Bitrise Build Cache CLI を使用してビルド出力と Gradle メタデータを保存します。
- ビルド出力とメタデータをキャッシュから復元します。
初期ビルドを実行して、必要なディレクトリをキーベースのキャッシュに保存します。
診断ビルドを実行して、Gradle 実行の理由を明らかにします。

診断ビルド用の CI 構成の作成

Gradle 診断ビルド用の CI 構成を作成するには、Bitrise ワークフローに、Bitrise Build Cache CLI を使用してビルド出力を保存および復元するための 2 つの新しいステップが必要になります。

キーベースのキャッシュを使用しない手順

診断ビルドではキーベースのキャッシュを使用しますが、この目的のために専用のキーベースのキャッシュ手順は使用しないでください。 スクリプト このガイドに記載されている手順。

ワークフローエディター

ビットライズ

診断ビルド用の新しいワークフローを作成します。

保管する場合は bitrise.yml ファイルリポジトリ内新しいブランチも作成し、そのブランチから診断ビルドを実行することをお勧めします。
追加する Gradle の Bitrise ビルドキャッシュをアクティブ化する ワークフローへのステップ。
Gradleタスクを実行するステップの後（例えば、 Android ビルド）、追加 スクリプト ステップ。

環境

スクリプトは、スピードアップしたい Gradle コマンドと同じ環境で実行してください。たとえば、ビルド全体で複数の Docker コンテナを使用する場合は、Bitrise Build Cache CLI が Gradle コマンドと同じ Docker コンテナで実行されるようにしてください。
にスクリプトの内容入力に以下を追加します。
```
/tmp/bin/bitrise-build-cache save-gradle-output-data
```
これにより、Gradle メタデータディレクトリとビルド出力が、ワークスペース、アプリ、ワークフロー固有のキャッシュキーの下のキーベースのキャッシュに保存されます。
Gradleタスクを実行するステップの前に、 スクリプト ステップ。
にスクリプトの内容入力に以下を追加します。
```
/tmp/bin/bitrise-build-cache restore-gradle-output-data
```
このステップはキャッシュにアクセスし、Gradle ビルドデータを復元します。

診断ビルド用の新しいワークフローを作成します。

保管する場合は bitrise.yml ファイルリポジトリ内新しいブランチも作成し、そのブランチから診断ビルドを実行することをお勧めします。
追加する activate-build-cache-for-gradle ワークフローへのステップ。
Gradleタスクを実行するステップの後（例えば、 android-build）、追加 script ステップ。

環境

スクリプトは、スピードアップしたい Gradle コマンドと同じ環境で実行してください。たとえば、ビルド全体で複数の Docker コンテナを使用する場合は、Bitrise Build Cache CLI が Gradle コマンドと同じ Docker コンテナで実行されるようにしてください。
に content 入力、追加:
```
- script:
  inputs:
  - content: |-
      /tmp/bin/bitrise-build-cache save-gradle-output-data
```
これにより、Gradle メタデータディレクトリとビルド出力が、ワークスペース、アプリ、ワークフロー固有のキャッシュキーの下のキーベースのキャッシュに保存されます。
Gradleタスクを実行するステップの前に、 script ステップ。
に content 入力、追加 /tmp/bin/bitrise-build-cache restore-gradle-output-data:
```
- script:
  inputs:
  - content: |-
      /tmp/bin/bitrise-build-cache restore-gradle-output-data
```
このステップはキャッシュにアクセスし、Gradle ビルドデータを復元します。

設定は次のようになります。

- activate-build-cache-for-gradle:
- script:
  inputs:
  - content: |-
      /tmp/bin/bitrise-build-cache restore-gradle-output-data
- gradle-runner:
  inputs:
  - gradle_options: "--stacktrace --stacktrace"
  - gradlew_path: "./gradlew"
  - gradle_task: assembleDebug
- script:
  inputs:
  - content: |-
      /tmp/bin/bitrise-build-cache save-gradle-output-data

キーベースのキャッシュにディレクトリを保存する

Gradle診断ビルドを初めてセットアップするときは、作成された構成必要なディレクトリをキーベースのキャッシュに保存します。この初期ビルドでは、呼び出しの詳細に実行理由は表示されません。

CI 構成が完了したら、ビルドを実行します。
ログをチェックして、アップロードが正常に完了したことを確認します。

診断ビルドの実行と確認

その後 CI構成が完了しましたそして初期ビルドが正常にアップロードされました必要なディレクトリをキーベースのキャッシュに追加すると、診断ビルドを実行してGradleタスクの実行理由を明らかにすることができます。最初のビルドと同じワークフローとブランチを使用していることを確認してください。

診断ビルドでは、Gradle は増分ローカルビルドのように動作します。

ビルドを実行します。
開けるビルドキャッシュページ。
その中で最新の呼び出し、必要なタスクを見つけます。青いアイコンは、タスク実行理由を含むタスクを表示します。

キャッシュタスク入力の変更やキャッシュミスを頻繁に引き起こす CI 構成に関連する変更が表示されます。

これらの理由を正しく解釈してデバッグするには、関連するGradleドキュメントまたは、デバッグのヒント。

Gradle 構成キャッシュ

概要

Gradle構成キャッシュは、Gradleプロジェクトの構成フェーズの結果をキャッシュし、後続のビルドで再利用することでビルド時間を短縮します。詳細については、以下をお読みください。 Gradleの公式ドキュメントBitrise Build Cache は、Gradle 8.6 以降のバージョンでこの機能をサポートしています。

構成キャッシュの設定

構成キャッシュを設定するには:

Bitrise Build Cache のサブスクリプションまたはトライアルがあることを確認してください。
ローカルでビルドを実行するには、 --configuration-cache フラグ。

これにより、Gradleプロジェクトが設定キャッシュをサポートするようになります。Gradle設定で設定キャッシュを有効にするには、 Gradleの公式ガイドを参照してください。
Bitriseを生成する個人アクセストークン。

トークンの一貫性

構成キャッシュが正しく機能するには、Gradle プラグインで使用される認証トークンがビルド間で一貫している必要があります。
Gradle 暗号化キーを生成します。
```
openssl rand -base64 16
```
キーを秘密名前 GRADLE_ENCRYPTION_KEY Bitrise プロジェクトで。

これにより、構成キャッシュの暗号化された値が、異なるビルド間で同じままになります。固定暗号化キーの使用は、Gradle バージョン 8.6 以降でサポートされています。Bitrise は、それより前の Gradle バージョンの Gradle 構成キャッシュをサポートしていません。
Bitriseを設定するワークスペーススラッグ環境変数として BITRISE_BUILD_CACHE_WORKSPACE_ID。
追加する Gradle の Bitrise ビルドキャッシュアドオンを有効にする ワークフローへのステップ。

ステップはバージョン 2.7.7 以降である必要があります。ステップをそれ以降に更新すると、構成キャッシュが 1 回だけ無効になります。この現象が発生した場合は、再構築して問題を修正してください。
追加する Gradle設定キャッシュを復元する そして Gradle キャッシュを復元する ワークフローで Gradle を呼び出す前の手順。

ステップは、キャッシュされた構成データを取得し、構成キャッシュが参照する成果物にアクセスできるようにします。

構成キャッシュディレクトリ

の Gradle設定キャッシュを復元する ステップはデータを保存します ./.gradle/configuration-cache ディレクトリ。これを上書きするには、構成キャッシュディレクトリ入力。

例えば、 Android ビルド Gradle プロジェクトをビルドするには、ワークフロー内でこれらの 2 つのステップがプロジェクトの前に来る必要があります。
追加する Gradle設定キャッシュを保存する そして Gradle キャッシュを保存 ワークフローでの Gradle 呼び出し後の手順。

ステップは、構成データをキャッシュに保存し、構成キャッシュによって参照される成果物を保存します。
有効にする変換を保存の入力 Gradle キャッシュを保存 ステップ。ステップバージョン 1.4.1 以降が必要です。

Gradle 構成キャッシュログの保存

Gradleのビルドログには、構成キャッシュを再利用しなかった理由に関する情報が含まれている場合があります。ログは遺物ビルドのページ:

有効にする --info ログレベル Gradle で。
追加する Bitrise.ioにデプロイ ワークフローへのステップ。
設定するディレクトリまたはファイルパスを展開する Gradle がファイルパスとして出力するものへの入力。

展開されたファイルは、遺物ページ: Bitrise CIを開き、プロジェクトを選択してからビルドを選択し、遺物タブ。

構成キャッシュのトラブルシューティング

ビルドで構成キャッシュが再利用されない場合は、いくつかの潜在的な問題を確認できます。

一般的なトラブルシューティング

依存関係キャッシュを利用するには、必ず Gradle キャッシュの保存/復元ステップを追加してください。Gradle 構成キャッシュは、存在する必要がある成果物を参照します。
構成キャッシュが完全に適用され、再利用されるまでに複数回の実行が必要になる場合があります。
Gradleが設定キャッシュを再利用しなかった理由を調べるには、Gradleログを確認してください。 Gradle設定キャッシュログを保存するビルド成果物に追加します。
アップデート Gradle の Bitrise ビルドキャッシュをアクティブ化する この手順により、構成キャッシュが 1 回だけ無効化されます。問題を修正するには、もう一度ビルドを実行してください。

クラスエラーの計測に失敗しました

次のエラーが発生してビルドが失敗する可能性があります。

org.gradle.internal.operations.BuildOperationInvocationException: Failed to instrument class io/bitrise/gradle/cache/BitriseBuildCache in ClassLoaderScopeIdentifier.Id{coreAndPlugins:init-file:/root/.gradle/init.d/bitrise-build-cache.init.gradle.kts(export)}

この問題を解決するには:

では Gradleキャッシュを保存する ステップ、設定変換を保存する入力する真実。

バージョン要件

入力はバージョン 1.4.1 以降でのみ利用可能です。
ビルドを実行せずに強制的に保存する Gradleキャッシュを復元する ステップ。

Gradle の依存関係の検証

Gradle の依存関係検証では、すべてのプラグインと依存関係が Gradle プロジェクトの検証メタデータ XML ファイルにリストされている必要があります。プラグインまたは依存関係が一覧表示されていない場合、Gradle は関連するプラグインと依存関係を一覧表示しているエラーで終了します

Bitrise ビルドキャッシュは、次の 2 つのカスタム Gradle プラグインを使用します。

Bitrise ビルドキャッシュ Gradle プラグインは Gradle のビルドキャッシュインターフェースを実装しています。
Bitrise Gradle アナリティクス Gradle プラグインはビルドイベントリスナーを実装しています。

ザル Gradle のビルドキャッシュ ステップによって必要な Gradle が生成されます。 .init これら 2 つのプラグインと必要な初期化設定を指定するファイル。このファイルが Gradle に存在する場合 .init.d ディレクトリを指定すると、Gradle は指定された設定を自動的に使用します。これらのプラグインはメタデータ XML ファイルには記載されていないため、これは依存関係の検証機能と矛盾します

依存関係の検証によるビルド・キャッシュの設定

Bitrise Build Cache for Gradle を依存関係の検証とともに使用できるようにするには、以下を行う必要があります。

プロジェクトのBitriseプラグインとその依存関係をリストアップしてください verification-metadata.xml ファイル。
をロックする Gradle 用のビルドキャッシュ 最新のパッチバージョンにステップアップしてください。Step を特定のバージョンにロックすると自動更新ができなくなり、ビルドでは常に同じバージョンの Step が使用されます。詳細については、以下をご覧ください。特定のステップバージョンを使用する。

そのためには:

を開くディペンデンシーマトリックスそして、最新バージョンを調べてください Gradle 用ビルドキャッシュ ステップ 1。
の中にコンフィギュレーション YAML プロジェクトのファイル。ステップを最新のパッチバージョンにロックします。

メタデータの更新

ロックされたステップのバージョンを変更するたびに、を更新する必要があります verification-metada.xml ファイル!
```
- [email protected]:
    inputs:
    - verbose: 'true'
```
に戻る依存関係マトリックスそして、ロックした Step バージョンに対応する CLI バージョンを確認します。
CLIバージョン番号のリンクをクリックして、CLIリリースページに移動します。
見つけて verification-metadata.xml ファイルを作成してダウンロードします。
の内容を追加してください コンポーネント ダウンロードしたファイルから、あなたの 1 つのファイルへの要素 $PROJECT_ROOT/gradle/verification-metadata.xml ファイル。

注記

シンプルな Gradle プロジェクトと特定のプロジェクトプラットフォームランタイムバージョンでプラグインの依存関係を収集しました。ご使用のセットアップでは、Gradle が引き出す依存関係は若干異なる場合があります。その場合は、依存関係メタデータを自分で生成する必要があります検証メタデータの生成と更新.
変更を確認してコミットします。

検証メタデータの生成と更新

次のような場合は、依存関係メタデータを自分で生成する必要があるかもしれません。

を更新します Gradle のビルドキャッシュ 新しいバージョンへのステップ。
メタデータ XML ファイルに収集されたメタデータは、Gradle がお客様の環境で想定しているものとは異なります。

をロックする Gradle 用のビルドキャッシュ 設定 YAML ファイルの最新バージョンにステップアップしてください。
を開くディペンデンシーマトリックスそして、ロックした Step バージョンに対応する CLI バージョンを確認します。

開発マシンまたは別の（本番環境ではない）ワークフローのBitriseに、そのバージョンのCLIをインストールします。replace CLIVERSION 以下のcurlコマンドで、インストールしたいバージョンを指定すると、 v0.15.9。
```
curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b /tmp/bin -d "CLIVERSION"
```
バックアップ $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts プロセスの次のステップで上書きされるためです。
ビットライズのCLIを実行する gradle-verification add-reference-deps コマンド:
```
/tmp/bin/bitrise-build-cache gradle-verification add-reference-deps
```
Gradle プロジェクトフォルダに、検証メタデータを書き込みます。例えば:
```
./gradlew tasks --write-verification-metadata sha256
```
メタデータの違いを確認してから、変更をコミットしてプロダクションワークフローに移行します。
バックアップした場合 $HOME/.gradle/init.d/bitrise-build-cache.init.gradle.kts、変更を元に戻すことができます。

このセクションの内容:

参照:

ステップワークスペース

Gradle のリモート ビルド キャッシュ