Skip to main content

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 診断ビルドをセットアップして実行するには:

  1. 次の CI 構成を作成します。

    • Bitrise Build Cache CLI を使用してビルド出力と Gradle メタデータを保存します。

    • ビルド出力とメタデータをキャッシュから復元します。

  2. 初期ビルドを実行して、必要なディレクトリをキーベースのキャッシュに保存します。

  3. 診断ビルドを実行して、Gradle 実行の理由を明らかにします。

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

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

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

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

ワークフローエディター

ビットライズ

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

    保管する場合は bitrise.yml ファイル リポジトリ内新しいブランチも作成し、そのブランチから診断ビルドを実行することをお勧めします。

  2. 追加する Gradle の Bitrise ビルド キャッシュをアクティブ化する ワークフローへのステップ。

  3. Gradleタスクを実行するステップの後(例えば、 Android ビルド)、追加 スクリプト ステップ。

    環境

    スクリプトは、スピードアップしたい Gradle コマンドと同じ環境で実行してください。たとえば、ビルド全体で複数の Docker コンテナを使用する場合は、Bitrise Build Cache CLI が Gradle コマンドと同じ Docker コンテナで実行されるようにしてください。

  4. スクリプトの内容 入力に以下を追加します。

    /tmp/bin/bitrise-build-cache save-gradle-output-data

    これにより、Gradle メタデータ ディレクトリとビルド出力が、ワークスペース、アプリ、ワークフロー固有のキャッシュ キーの下のキーベースのキャッシュに保存されます。

  5. Gradleタスクを実行するステップの前に、 スクリプト ステップ。

  6. スクリプトの内容 入力に以下を追加します。

    /tmp/bin/bitrise-build-cache restore-gradle-output-data

    このステップはキャッシュにアクセスし、Gradle ビルド データを復元します。

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

    保管する場合は bitrise.yml ファイル リポジトリ内新しいブランチも作成し、そのブランチから診断ビルドを実行することをお勧めします。

  2. 追加する activate-build-cache-for-gradle ワークフローへのステップ。

  3. Gradleタスクを実行するステップの後(例えば、 android-build)、追加 script ステップ。

    環境

    スクリプトは、スピードアップしたい Gradle コマンドと同じ環境で実行してください。たとえば、ビルド全体で複数の Docker コンテナを使用する場合は、Bitrise Build Cache CLI が Gradle コマンドと同じ Docker コンテナで実行されるようにしてください。

  4. content 入力、追加:

    - script:
      inputs:
      - content: |-
          /tmp/bin/bitrise-build-cache save-gradle-output-data

    これにより、Gradle メタデータ ディレクトリとビルド出力が、ワークスペース、アプリ、ワークフロー固有のキャッシュ キーの下のキーベースのキャッシュに保存されます。

  5. Gradleタスクを実行するステップの前に、 script ステップ。

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

  1. CI 構成が完了したら、ビルドを実行します。

  2. ログをチェックして、アップロードが正常に完了したことを確認します。

    upload-complete.png

診断ビルドの実行と確認

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

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

  1. ビルドを実行します。

  2. 開ける ビルドキャッシュページ

  3. その中で 最新の呼び出し、必要なタスクを見つけます。青いアイコンは、タスク実行理由を含むタスクを表示します。

    invocations-significant.png

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

    task-reason.png

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