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

GitHub ActionsでのBuild Cache for Gradleの設定

Bitrise Build Cacheを使用すると、CIをBitriseに移行することなく、GitHub Actions ワークフローのGradleビルドを高速化できます。GitHubがホストするランナーでも、Bitrise Build Hub ランナーでも、同じように動作します。

ワークフローには2つの追加ステップが必要です。1つはBitrise Build Cache CLIをインストールするステップ、もう1つはGradleのキャッシュを有効にするステップです。その後に同じジョブ内で実行されるすべてのGradleステップが、このキャッシュを使用します。

手順を手動で実行する代わりに、AIコーディングエージェントを使ってセットアップすることもできます。Getting started with AIを参照してください。

認証Click to copy link​

GitHub Actions で Bitrise Build Cache CLI を認証する方法は3つあります。最適な方法は、ジョブの実行場所によって異なります。

Bitrise Build Hub ランナーでは、設定は不要です。マシンはすでに Bitrise Workspace に接続されているため、CLI がマシンから認証情報を取得します。トークンを作成する必要はなく、ワークフローにシークレット、変数、環境変数を追加する必要もありません。

マシンプールは、使用する Build Cache と同じ Workspace に属している必要があります。

最小 CLI バージョン

Build Hub ランナーでの自動認証には、Bitrise Build Cache CLI v3.10.0 以降が必要です。このページのインストールコマンドは常に最新リリースを取得するため、CLI を古いバージョンに固定している場合にのみ関係します。古い CLI はマシンの認証情報を認識できず、トークンがないというエラーで停止します。

CLI が Bitrise に接続してトークンを取得できない場合は、このページの他の方法にフォールバックします。BITRISE_BUILD_CACHE_AUTH_TOKEN と BITRISE_BUILD_CACHE_WORKSPACE_ID も設定しているジョブは引き続き動作し、それらの値がマシン自体の認証情報よりも優先されます。

ワークフローへのBuild Cacheの追加Click to copy link​

  1. Bitrise Build Cache CLIをインストールするステップを追加します。

    - name: Install the Bitrise Build Cache CLI
      run: curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b /tmp/bin -d

  2. Gradleを実行するステップの前に、Build Cache for Gradleを有効にするステップを追加します。

    - name: Activate Bitrise Build Cache for Gradle
      run: /tmp/bin/bitrise-build-cache activate gradle --cache --cache-push

    --cacheはキャッシュからの読み取りを有効にし、--cache-pushはキャッシュへの書き込みを有効にします。通常、CIはキャッシュを作成する環境であるため、両方とも有効にしておいてください。

    Containers

    ジョブがコンテナー内、または複数のコンテナー内で実行される場合、CLIは、高速化するGradleコマンドと同じコンテナー内で実行する必要があります。

ワークフローの例Click to copy link​

name: build

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      BITRISE_BUILD_CACHE_AUTH_TOKEN: ${{ secrets.BITRISE_BUILD_CACHE_AUTH_TOKEN }}
      BITRISE_BUILD_CACHE_WORKSPACE_ID: ${{ vars.BITRISE_BUILD_CACHE_WORKSPACE_ID }}
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: temurin

      - name: Install the Bitrise Build Cache CLI
        run: curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b /tmp/bin -d

      - name: Activate Bitrise Build Cache for Gradle
        run: /tmp/bin/bitrise-build-cache activate gradle --cache --cache-push

      - name: Build
        run: ./gradlew assembleDebug

ベストプラクティスと制限事項Click to copy link​

アクティベーションは独立したステップとして実行するClick to copy link​

CLIは、$GITHUB_ENVを通じて設定を公開します。GitHub Actions は、この設定をジョブの後続のステップに適用します。Build Cacheのアクティベーションとビルドの実行を同じrun:ブロック内で行うと、ビルドは設定を認識しません。

アクティベーションは、ビルドを実行するステップより前の独立したステップで行ってください。

Workflows：フォークからトリガーされた実行にはシークレットがありませんClick to copy link​

GitHubは、フォークからトリガーされたワークフローの実行に、リポジトリや Organization のシークレットを渡しません。そのような実行ではBITRISE_BUILD_CACHE_AUTH_TOKENが空になるため、CLIは認証できず、ビルドはキャッシュなしで実行されます。

依存関係のキャッシュとBuild Cacheを分けて考えるClick to copy link​

actions/cacheは依存関係のキャッシュを行います。GradleやCocoaPodsのキャッシュなど、ビルドがダウンロードするパッケージを保存し、次回の実行時に復元することで、再度取得する必要をなくします。Bitrise CIでは、キーベースのキャッシュStepsが同じ役割を果たします。詳細については、Dependencies and caching overviewを参照してください。

これは、ビルド自体の出力（コンパイル済みクラス、コンパイル済みソース、タスクの結果）を再利用するBitrise Build Cacheとは別の役割です。この2つは組み合わせて効果を発揮するため、引き続き依存関係をキャッシュしてください。

やってはいけないのは、ビルドの出力をdependency cacheに含めることです。たとえば、actions/cacheがGradleのローカルのbuild cacheディレクトリ（~/.gradle/caches/build-cache-1）を復元すると、復元されたローカルコピーが、Bitrise Build Cacheが提供するはずの結果を返してしまい、リモートキャッシュのヒット率がほぼゼロまで低下します。キャッシュするのは依存関係のディレクトリであり、ビルド出力のディレクトリではありません。

セットアップの確認Click to copy link​

  1. ワークフローを実行します。アクティベーションStepが正常に完了し、接続したキャッシュエンドポイントがログに記録されるはずです。
  2. WorkspaceのBuild Cacheページを開きます。実行したビルドが、ビルドのキャッシュ統計とともにinvocation listに表示されます。
  3. 最初の実行では、キャッシュヒット率は0%と報告されます。この時点ではキャッシュが空のためで、想定どおりの動作です。
  4. キャッシュをウォームアップするため、ワークフローをさらに1～3回実行してください。ヒット率が0%を超えるはずです。

関連情報