- Bitriseドキュメントへようこそ!
- 依存関係とキャッシュ
- リモートビルドキャッシュ
- Gradle のリモート ビルド キャッシュ
Gradle のリモート ビルド キャッシュ
Bitrise リモート ビルド キャッシュを使用すると、ローカル ビルドと CI ビルドの両方に Gradle ビルド キャッシュを利用できます。このソリューションは、Gradle タスクの出力をリモート サーバーにキャッシュします。ビルドを実行するとき、Gradle は出力がリモート キャッシュで利用可能なタスクを実行せず、代わりにキャッシュ エントリをダウンロードします。
無料でお試しください
30 日間の無料トライアルを無料でご提供しています。お支払い情報を提供する必要もありません。トライアルは、Bitrise Build Cache を設定すると自動的に開始されます。
Bitrise Build Cacheを使い始めるにはここをクリックしてくださいBitrise アカウントをお持ちでない場合は、ビルド キャッシュの設定に進む前に、まずアカウントを作成するように求められます。
Gradle ビルド キャッシュ 他のビルドによって生成された出力を再利用することで時間を節約できます。Bitrise ビルド キャッシュを使用すると、Bitrise と他の CI 環境の両方で CI ビルドに利用できます。
Gradle ビルドは、入力と出力を含む一連のタスクです。 Bitrise は、タスクの出力をパフォーマンスの高いリモート サーバーにキャッシュします。 Gradle ビルドを開始すると、Gradle は出力がリモート キャッシュにあるタスクの実行をスキップし、代わりにキャッシュ エントリをダウンロードして再利用します。
依存関係のキャッシュとビルドのキャッシュ
ビルド キャッシュと依存関係キャッシュは別の概念です。ベスト プラクティスは、ビルド時間を最小限に抑えるために両方を使用することです。続きを読む: Gradle 依存関係のキャッシュ。
キーベースの依存関係キャッシュを使用する
従来の依存関係キャッシュのステップをリモート ビルド キャッシュと組み合わせて使用しないことをお勧めします。代わりに、ビルド キャッシュのみを組み合わせてください。 キーベースの依存関係のキャッシュ。これは、従来の依存関係キャッシュがビルド間でビルド設定を引き継ぐときに発生する可能性のある予期せぬ結果を防ぐためです。
Bitrise CI 環境での Gradle 用 Bitrise ビルド キャッシュの設定
Bitrise CI環境では、公式の ステップ Gradle ビルドに Bitrise ビルド キャッシュを使用します。
Bitriseビルドキャッシュを使用する場合 ローカルビルドでまず、CI 環境で有効化する必要があります。
ワークフローエディター
ビットライズ.yml
-
でアプリを開きます ビットライズ。
-
クリック ワークフロー メインページのボタン。
-
を追加します。 Gradle の Bitrise ビルド キャッシュをアクティブ化する ワークフローに進みます。
このステップは、次のような Gradle タスクを実行するステップの前にある必要があります。 グラドルランナー また Android ビルド。
-
を開きます。
bitrise.yml
ファイルを追加して、activate-build-cache-for-gradle
ワークフローに進みます。このステップは、次のような Gradle タスクを実行するステップの前にある必要があります。
gradle-runner
またandroid-build
。your-workflow: steps: - git-clone@8: {} - activate-build-cache-for-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ドキュメント または、 デバッグのヒント。