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

GitHub ActionsでのBuild Cache for Bazelの設定

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

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

手動で手順を進める代わりに、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: |
        mkdir -p "$HOME/.local/bin"
        curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b "$HOME/.local/bin" -d
        echo "$HOME/.local/bin" >> "$GITHUB_PATH"

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

    - name: Activate Bitrise Build Cache for Bazel
      run: bitrise-build-cache activate bazel --cache --cache-push

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

    コンテナー

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

  3. Workspace で Remote Build Execution が有効になっている場合は、--rbe フラグを追加することで、GitHub Actions からも使用できます。

    RBE の有効化

    RBE を有効にする前に、Workspace 用のワーカーと、リポジトリの .bazelrc ファイル内のプール設定を用意しておく必要があります。詳細については、Remote Build Execution for Bazelを参照してください。

ワークフローの例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

      - name: Install the Bitrise Build Cache CLI
        run: |
          mkdir -p "$HOME/.local/bin"
          curl --retry 5 -sSfL 'https://raw.githubusercontent.com/bitrise-io/bitrise-build-cache-cli/main/install/installer.sh' | sh -s -- -b "$HOME/.local/bin" -d
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"

      - name: Activate Bitrise Build Cache for Bazel
        run: bitrise-build-cache activate bazel --cache --cache-push

      - name: Build
        run: bazel build //...

ベストプラクティスと制限事項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%を超えるはずです。

関連情報