メインコンテンツまでスキップ

Gradleの実行理由の診断ビルド

キャッシュヒット率とは、キャッシュが受け取ったリクエスト数に対して、そのうち何件のコンテンツリクエストを正常に処理できたかを示す指標です。キャッシュミスが多いと、キャッシュを十分に活用できないため、ビルドが遅くなります。

Gradleのタスクを実行する際、タスクの入力が変更されると、通常はキャッシュミスが発生します。Gradleの実行理由を確認すると、入力が変更された原因を把握し、問題をデバッグするのに役立ちます。

Gradleのタスクとそのキャッシュの仕組みについて詳しく知りたい場合は、このまま読み進めてください。

Bitriseで診断ビルドを設定する方法を確認するには、診断ビルドに進んでください。

GradleのタスクとキャッシュClick to copy link​

Gradleのビルドシステムでは、基本的な処理の単位はタスクです。タスクは、クラスのコンパイル、単体テストの実行、JAR の作成などを行います。各タスクには、ファイルや環境変数などの入力と、出力があります。

タスクは通常、モジュールごとに設定できる特定のビルドディレクトリに出力を生成します。このディレクトリの内容は、同じマシン上のビルド間で再利用できる場合が多くあります。そのため、Gradleは再利用できないタスクだけを実行して時間を節約します。その他のタスクでは、ビルドディレクトリの出力が再利用され、タスクにはUP-TO-DATEラベルが付きます。このプロセスは、Gradleでインクリメンタルビルドと呼ばれています。

インクリメンタルビルドとインクリメンタルなタスク実行の違い

インクリメンタルビルドは、インクリメンタルなタスク実行とは異なります。インクリメンタルなタスクについては、Gradleの公式ドキュメントを参照してください。

Gradleのタスク(CI環境)Click to copy link​

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

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

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

タスクのキャッシュClick to copy link​

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

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

タスクにUP-TO-DATEラベルが付いていない場合、その理由が記録され、Bitriseのinvocation detailsにあるタスクの行に表示されます。考えられる理由の例は次のとおりです。

  • メタデータが存在しない場合、No history available と表示されます。
  • 出力が存在しない場合、Output... has been removed と表示されます。
  • UP-DO-DATEラベルが付いていないタスクでも、過去に入力が一度以上キャッシュされていれば、キャッシュできます。

診断ビルドClick to copy link​

タスクが実行される原因となった変更を把握するには、Gradleのメタデータと、以前のビルドのビルド出力が必要です。これらをCI環境に復元すると、ローカルのインクリメンタルビルドをシミュレートでき、キャッシュミスの原因となるビルド間の変更を確認できます。

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

デバッグ専用

診断ビルドはキーベースのキャッシュを多用し、ビルド時間が長くなります。診断ビルドの目的はデバッグであり、日常のWorkflowに組み込むべきではありません。

キーベースのキャッシュのアーカイブ上限は 15 Gb です。アプリの出力がこの上限を超える場合は、独自のartifact storageソリューションを使用して、同じ原則で2回に分けてビルドを実行できます。

Gradleの診断ビルドを設定して実行するには、次の手順を行います。

  1. 次の内容を含むCIの設定を作成します。

    • BitriseBuild CacheCLIを使用して、ビルド出力とGradleのメタデータを保存します。
    • キャッシュからビルド出力とメタデータを復元します。
  2. 初回のビルドを実行して、必要なディレクトリをキーベースのキャッシュに保存します。

  3. 診断ビルドを実行して、Gradleの実行理由を確認します。

診断ビルド用のCI設定の作成Click to copy link​

Gradleの診断ビルド用にCIの設定を作成するには、BitriseWorkflowに、ビルド出力を保存および復元するための新しいStepsを2つ追加する必要があります。これらには、BitriseBuild CacheCLIを使用します。

キーベースのキャッシュStepsは使用しないでください

診断ビルドではキーベースのキャッシュを使用しますが、この目的では、専用のキーベースのキャッシュStepsは使用しないでください。このガイドの説明に従って、Script Stepsを設定してください。

  1. 診断ビルド用にCreate a new Workflow。

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

  2. Workflowに Build Cache for Gradle Stepを追加します。

  3. Gradleタスクを実行するStepの後(例: Android Build)に、Script Stepを追加します。

    環境

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

  4. Script content 入力に、次の内容を追加します。

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

    これにより、Gradleのメタデータディレクトリとビルド出力が、Workspace、アプリ、Workflowごとに一意のcache keyでキーベースのキャッシュに保存されます。

  5. Gradleタスクを実行するStepの前に、もう1つ Script Stepを追加します。

  6. Script content 入力に、次の内容を追加します。

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

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

キーベースのキャッシュへのディレクトリの保存Click to copy link​

Gradleの診断ビルドを初めて設定する場合は、作成した設定で初回のビルドを実行して、必要なディレクトリをキーベースのキャッシュに保存する必要があります。この初回のビルドでは、invocation detailsに実行理由は表示されません。

  1. CIの設定が完了したら、ビルドを実行します。

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

    upload-complete.png

診断ビルドの実行と確認Click to copy link​

CIの設定が完了し、初回のビルドが必要なディレクトリのアップロードに成功してキーベースのキャッシュに保存されたら、診断ビルドを実行して、Gradleのタスクの実行理由を確認できます。初回のビルドと同じWorkflowとブランチを使用してください。

診断ビルドでは、Gradleはローカルのインクリメンタルビルドであるかのように動作します。

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

  2. Build Cacheページを開きます。

  3. Latest invocations の中から、必要なタスクを探します。青いアイコンは、タスクの実行理由が含まれているタスクを示します。

    invocations-significant.png

    CIの設定に関連する変更が表示されます。これらの変更は、タスクの入力変更やキャッシュミスの原因となることがよくあります。

    task-reason.png

これらの理由を正しく解釈してデバッグするには、Gradleの関連ドキュメントを確認するか、デバッグのヒントを参照してください。