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

GitHub ActionsでのBuild Cache for Xcodeの設定

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

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

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

要件Click to copy link​

  • Xcode 26 or later。Xcode Compilation Cache は、これより前のバージョンでは利用できません。
  • Bitrise Build Cache CLI v1.0.0 以降。すでに別のビルドツール用に CLI をインストールしている場合は、固定するバージョンが Xcode をサポートしていることを確認してください。

認証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. xcodebuild を実行するステップの前に、Build Cache for Xcode を有効にするステップを追加します。

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

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

    xcodebuild を PATH 経由で呼び出す

    有効化すると、ラップされた xcodebuild が PATH の先頭に配置されます。/usr/bin/xcodebuild のようにバイナリを絶対パスで直接呼び出すコマンドはラッパーを経由しないため、キャッシュされません。これは、ユーザーに代わって xcodebuild や xcrun を絶対パスで呼び出すツールにも当てはまります。

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

name: build

on: [push, pull_request]

jobs:
  build:
    runs-on: macos-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: 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 Xcode
        run: /tmp/bin/bitrise-build-cache activate xcode --cache --cache-push

      - name: Build
        run: |
          xcodebuild build-for-testing \
            -workspace MyApp.xcworkspace \
            -scheme MyApp \
            -destination 'generic/platform=iOS Simulator'

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

関連情報