GitHub アクション

インストールステップとこのプラグインのフルマークダウンガイドのすべてのステップを含む設定プロンプトをコピーする

GitHub リポジトリから直接 iOS と Android のビルドを自動化できます。ワークフローファイル 1 つとリポジトリのシークレット数少ない数で、チームの誰も Mac、Xcode、または Android Studio をインストールする必要なく、プッシュ、タグ、または手動トリガーごとに署名された、ストアに準備されたアプリが生成されます。

何が得られるか

手動作業なしのリリース

Git でのリリースタグを付与すると、自動的に TestFlight と Play Store に署名された iOS と Android のバイナリが送信されます。

ローカル設定なし

WindowsまたはLinuxのContributorsはiOSビルドをトリガーできます。Xcode、プロビジョニングのハッスル、ローカルに共有されている署名証明書は必要ありません。

スコープされたシークレット

GitHubリポジトリのシークレット内にクレデンシャルが保存されます。スコープはリポジトリに限定され、ワークフロー実行者にのみ表示されます。回転が簡単、監査も簡単です。

並列ビルド

iOSとAndroidを同時にビルドするマトリックスジョブ。通常のリリースは10分未満で完了します。

前提条件

__CAPGO_KEEP_0__アカウントと有効なサブスクリプションが必要です。__CAPGO_KEEP_0__ __CAPGO_KEEP_1__キーも必要です。

Capgoにアプリを登録する必要があります。 Capgo API key
Capgobunx @capgo/cli@latest app add __CAPGO_KEEP_1__
ローカルに設定したクレデンシャルでビルド bunx @capgo/cli@latest build init — 以下を参照クレデンシャル管理ワークショップのためのガイド
ローカルビルドが成功した場合 (bunx @capgo/cli@latest build request com.example.app --platform android --build-mode debugCIは最初のビルドをデバッグする場所ではありません
The GitHub CLI (gh) インストール済みかつ認証済み (gh auth login)

セットアップ

The Capgo CLI can export your local credentials as a ready-to-use .env ローカル認証情報を __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ としてエクスポートできます。 gh secret set -f、これを組み合わせると、CI/CD 設定全体を 3 つのコマンドで実行できます — マニュアルの base64 エンコード、JSON の操作、秘密情報のコピーとペーストは必要ありません。

Capgo API キーをリポジトリのシークレットとして追加してください。

API キーはアプリごとに保存される認証情報のストアに含まれていないため、手動で 1 回追加してください。
ターミナル画面
```
gh secret set CAPGO_TOKEN --body "your_capgo_api_key_here"
```
__CAPGO_KEEP_0__ ダッシュボードでキーの生成 Capgo dashboard GitHub Actionsとともに アップロード 権限が高い
環境変数をファイルにエクスポートする .env ファイル

インタラクティブな環境変数マネージャーを実行します
ターミナルウィンドウ
```
bunx @capgo/cli@latest build credentials manage --appId com.example.app
```
TUIで 環境変数を.envファイルにエクスポートするです。CLIは .env.capgo.<appId> 現在のディレクトリにモードで書き込まれます 0600 (オーナーが読むのみ) — 例えば、 .env.capgo.com.example.app. iOS と Android の両方が設定されている場合、両方のプラットフォームのシークレットは同じファイルの下に配置されます。 # === IOS === そして # === ANDROID === セクションヘッダー。 iOS と Android の環境変数名は互いに異なるため、組み合わせることは競合しない。

Pass --platform ios (または --platform android)を使用して、管理者を 1 つのプラットフォームにスコープすることができます。その後、エクスポートは各プラットフォームごとにファイルを作成します。例えば、 .env.capgo.com.example.app.ios. iOS と Android のシークレットが異なるリポジトリまたは環境に存在する場合、有用です。

Aの設定スイッチのグループ(BUILD_OUTPUT_UPLOAD_ENABLED, BUILD_OUTPUT_RETENTION_SECONDS, SKIP_BUILD_NUMBER_BUMP, CAPGO_IOS_DISTRIBUTION)は各プラットフォームごとに独立して保存でき、値が異なる可能性があります。管理者が値の差異を検知すると、競合するキーを表示し、書き込み前に明示的な確認を求め、ファイルの先頭に競合リストをコメントとして埋め込みます。再エクスポートするには --platform if を使用して、各プラットフォームごとの値を保存する必要がある場合。
ファイルを __CAPGO_KEEP_0__ Actions secrets にプッシュしてください。 .env file to GitHub Actions secrets

ターミナルウィンドウ gh secret set -f コピー KEY=value それだけです。ワークフローのすべてのシークレットが __CAPGO_KEEP_0__ に保存されています。確認するには
.envファイルをコミットしないでください
```
gh secret set -f .env.capgo.com.example.app
```
That’s it — every secret your workflow needs is now in GitHub. gh secret list.
コミットしないでください。
GitHubにプッシュした後、
ターミナルウィンドウ
echo '.env.capgo.*' >> .gitignore rm .env.capgo.*
必要に応じてクレデンシャルをローテートするために、ファイルは長期間のアーティファクトではありません。
ワークフローファイルを作成

追加 .github/workflows/capgo-build.yml リポジトリに追加してください。

どのトリガーペターを選択するかは、ビルドを起動する方法によって異なります。

参考として gh secret set -f これらのリポジトリシークレットを作成します (ワークフローのYAMLはこれらの正確な名前で参照します):

プラットフォーム	シークレットの作成
iOS	`BUILD_CERTIFICATE_BASE64`, `P12_PASSWORD`, `CAPGO_IOS_PROVISIONING_MAP_BASE64`, `APPLE_KEY_ID`, `APPLE_ISSUER_ID`, `APPLE_KEY_CONTENT`, `APP_STORE_CONNECT_TEAM_ID`
Android	`ANDROID_KEYSTORE_FILE`, `KEYSTORE_KEY_ALIAS`, `KEYSTORE_KEY_PASSWORD`, `KEYSTORE_STORE_PASSWORD`, `PLAY_CONFIG_JSON`
手動で追加	`CAPGO_TOKEN`

必要ありません。これらのワークフロー例は、すべてのものを参照しています。

ワークフロー例

3 つの例は、最も一般的なパターンをカバーしています。すべて同じ形を使用します: リポジトリをチェックアウト、依存関係をインストール、Web アセットをビルド、ネイティブに Sync、最後に Capgo を Build して、環境変数として資格情報を渡します。

1. 手動トリガー

誰でも書き込みアクセス権を持っている人が、ビルドをトリガーすることができます。 アクション GitHub内にあるプラットフォームのドロップダウン。アドホックのテストビルドやリリースをオンデマンドで開始するのに役立ちます。

name: Capgo Build (Manual)

on:
  workflow_dispatch:
    inputs:
      platform:
        description: 'Platform to build'
        required: true
        default: 'android'
        type: choice
        options: [ios, android, both]
      mode:
        description: 'Build mode'
        required: true
        default: 'debug'
        type: choice
        options: [debug, release]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: latest

      - run: bun install --frozen-lockfile
      - run: bun run build
      - run: bunx cap sync

      - name: Trigger Capgo Build
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
          CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }}
          APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }}
          APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }}
          APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }}
          APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }}
          ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }}
          KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
          KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
          KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
          PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }}
        run: |
          bunx @capgo/cli@latest build request com.example.app \
            --platform ${{ inputs.platform }} \
            --build-mode ${{ inputs.mode }}

置き換え com.example.app アプリIDに置き換えてください。コミットした後、 アクション → Capgo ビルド (手動) → ワークフロー実行 をクリックしてください。

2. タグによるリリース

両方のプラットフォームを並行してビルドし、バージョンタグのようなものをプッシュすると同時に配信します。こののは、最も一般的なプロダクション設定です— v1.4.0アクション git tag v1.4.0 && git push --tags リリースコマンドになります。

name: Capgo Build (Release)

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        platform: [ios, android]
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: latest

      - run: bun install --frozen-lockfile
      - run: bun run build
      - run: bunx cap sync ${{ matrix.platform }}

      - name: Build ${{ matrix.platform }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
          # iOS
          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
          CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }}
          APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }}
          APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }}
          APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }}
          APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }}
          # Android
          ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }}
          KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
          KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
          KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
          PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }}
        run: |
          bunx @capgo/cli@latest build request com.example.app \
            --platform ${{ matrix.platform }} \
            --build-mode release

マトリックスはiOSとAndroidを並行して、別々の実行者で実行します。設定 fail-fast: false iOSのビルドが失敗しても、進行中のAndroidのビルドをキャンセルしない (逆も同様) — 一時的な署名問題があるプラットフォームがある場合に便利です。

3. メインにプッシュしたときにデバッグビルド

プッシュのたびに、メインへのプッシュ時にデバッグ用のAndroidビルドを生成することで、ネイティブビルドの不具合を早期に検出します。 mainコストが安く、フィードバックが速く、プレイストアのアップロードをスキップして、純粋にSmokeテストとして機能させることができます。

name: Capgo Build (Main)

on:
  push:
    branches: [main]
    paths:
      - 'src/**'
      - 'android/**'
      - 'ios/**'
      - 'package.json'
      - 'capacitor.config.*'

jobs:
  smoke-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
        with:
          bun-version: latest

      - run: bun install --frozen-lockfile
      - run: bun run build
      - run: bunx cap sync android

      - name: Smoke build (Android debug)
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
          ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }}
          KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
          KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
          KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
        run: |
          bunx @capgo/cli@latest build request com.example.app \
            --platform android \
            --build-mode debug \
            --no-playstore-upload \
            --output-upload

フィルタ paths ドキュメントのみの変更の場合、ワークフローが実行されないようにします。 --no-playstore-upload プレイストアの提出をスキップ (必要ありません)、および PLAY_CONFIG_JSON 結果のAPKのダウンロードURLを生成して、テストデバイスにインストールできるようにします。 --output-upload 共通パターン

セクションのタイトル “共通パターン”

Play Store / TestFlight へのアップロードをスキップ

テストビルドの場合、ストアの提出をスキップします: Androidは --no-playstore-uploadを使用し、iOSの場合はアドホックモードでビルドします --ios-distribution ad_hoc (これはApp Storeに提出されることはありません)。これを --output-upload で組み合わせると、バイナリの時間制限付きダウンロードURLが取得できます。

ストアリリースの提出

デフォルトでは、リリースビルドは署名済みアーティファクトをアップロードし、最終的なストアアクションをあなたのコントロール下に残します。CIリリースがストアのレビューフローに直接移動するようにするには、 --submit-to-store-review.

Androidはあなたの PLAY_CONFIG_JSON サービスアカウントを使用します。 トラックを明示的に指定しない場合 --submit-to-store-review デフォルトでは、生産トラックに設定されます。 release_status: completed. 呼び出し元でトラックを明示的に指定することをお勧めします。 --android-track (または PLAY_STORE_TRACK), そしてステータスをオーバーライドするには --android-release-status / PLAY_STORE_RELEASE_STATUS 必要な場合:

- name: Submit Android release for review
  env:
    CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
    ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }}
    KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
    KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
    KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
    PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }}
  run: |
    npx @capgo/cli@latest build request com.example.app \
      --platform android \
      --build-mode release \
      --submit-to-store-review \
      --android-track production \
      --store-release-name "${GITHUB_REF_NAME}" \
      --store-release-notes "Release ${GITHUB_REF_NAME}" \
      --store-release-notes-locale "en-US=Release ${GITHUB_REF_NAME}"

内部の完了リリースの場合、生産ではなく:

- name: Submit Android internal release
  env:
    CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
    ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }}
    KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }}
    KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }}
    KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }}
    PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }}
  run: |
    npx @capgo/cli@latest build request com.example.app \
      --platform android \
      --build-mode release \
      --submit-to-store-review \
      --android-track internal \
      --store-release-name "${GITHUB_REF_NAME}"

iOSはApp Store Connect API キーパスを使用し、処理済みのTestFlightビルドをApp Storeレビューに提出します。 app_store 配布が必要です。 --ios-testflight-groups 外部ベータ配布用にオプションで、App Storeレビューには必要ありません。

- name: Submit iOS build to App Store review
  env:
    CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
    BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
    P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
    CAPGO_IOS_PROVISIONING_MAP: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP }}
    APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }}
    APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }}
    APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }}
    APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }}
  run: |
    npx @capgo/cli@latest build request com.example.app \
      --platform ios \
      --build-mode release \
      --ios-distribution app_store \
      --submit-to-store-review \
      --store-release-name "${GITHUB_REF_NAME}" \
      --store-release-notes "Release ${GITHUB_REF_NAME}" \
      --store-release-notes-locale "en-US=Release ${GITHUB_REF_NAME}" \
      --no-ios-automatic-release

ビルド出力URLとQRコードを読みます: code

成功したビルドのときに、ビルドアーティファクトURLとQRコードをディスクに保存し、次のステップで読み戻すことができます。 --output-record <path> to persist the build artifact URL and QR code to disk when the build succeeds, then read it back in subsequent steps with build last-outputクリップボードにコピー

- name: Build
  env:
    CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
    # ...credentials...
  run: |
    bunx @capgo/cli@latest build request com.example.app \
      --platform android --build-mode debug \
      --output-upload --output-retention 1d \
      --output-record /tmp/build.json

- name: Comment on PR with build URL
  env:
    GH_TOKEN: ${{ github.token }}
  run: |
    URL=$(bunx @capgo/cli@latest build last-output --path /tmp/build.json --field outputUrl)
    if [ -n "$URL" ]; then
      gh pr comment ${{ github.event.pull_request.number }} \
        --body "Debug build ready: $URL"
    fi

--output-record /tmp/build.json writes a JSON record (with jobId, status, outputUrl, qrCodeAscii, qrCodePngPath, finishedAt) and a PNG QR code alongside at /tmp/build.json.qr.png. build last-output reads it back:

--field outputUrl URLをダウンロードするのみ（改行終端；プルリクコメント内で安全） URL=$(...)).
--field qrCodePngPath PRにアップロードできるPNGパスを出力します。
--qr レンダリングされたASCII QRコードを出力します。PRコメント内にMarkdowncodeで囲んで、インラインスキャナビリティを実現します。

デフォルトでは、各リリースビルドではビルド番号を増分します。Gitタグなどの値を制御するには、次のようにパスを渡してください。

Skip build number bumping --skip-build-number-bump:

- name: Set version from tag
  run: |
    VERSION="${GITHUB_REF#refs/tags/v}"
    # Update package.json or your version source here
    bun pm version "$VERSION" --no-git-tag-version

- name: Build
  env:
    CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
    # ...credentials...
  run: |
    bunx @capgo/cli@latest build request com.example.app \
      --platform ios --build-mode release \
      --skip-build-number-bump

キャッシュ依存関係

bun install すでに高速化されているため、JS依存キャッシュはほとんどの場合有効ではないが、Capacitorのネイティブ依存関係 (CocoaPods、Gradle) は大規模プロジェクトではキャッシュする価値がある:

- uses: actions/cache@v4
  with:
    path: |
      ~/.bun/install/cache
      ios/App/Pods
      android/.gradle
    key: ${{ runner.os }}-capgo-${{ hashFiles('**/bun.lock', '**/Podfile.lock') }}

トラブルシューティング

症状	原因
`CAPGO_TOKEN is not set`	シークレットが追加されていない、またはジョブがそれにアクセスできない (環境/ブランチ保護を確認)
iOS/Android認証情報が欠落している	`gh secret set -f` 実行されていない、または別のリポジトリに対して実行された。 `gh secret list`
`cap sync` CIで失敗するがローカルでは動作する	ネイティブプラグインはありません `package.json`、または忘れていました `bun install` 前 `cap sync`
CIでビルドが成功するがアプリがApp Store Connectに表示されない	チームIDが間違っています、またはApp Store Connectにアプリレコードがまだ存在していません。ローカルで確認してください。 `bunx @capgo/cli@latest build credentials manage`
ビルドが「プロジェクトのアップロード」でハングする	プロジェクトアーカイブが通常より大きい場合、プロジェクトアーカイブがアップロードされていないことを確認してください `node_modules` プロビジョニングマップがXcodeが署名しているbundle IDと異なるbundle IDを指している場合、プロファイルを再読み込みし、再エクスポートしてください
`Provisioning profile doesn't match bundle ID`	ローカルでクレデンシャルが変更されたがCIで失敗する `build init` 前 `build credentials manage`
前	忘れずに再エクスポートして再プッシュしてください: `bunx @capgo/cli@latest build credentials manage` → `gh secret set -f .env.capgo.<appId>`
マネージャーは組み合わせたファイルを書き込まない	プラットフォーム間で共有設定キーが異なる場合、マネージャーは警告を表示し、確認を求めます。確認して上書きするか、プラットフォームごとに再エクスポートするかを選択します。 `--platform ios` / `--platform android`
`build last-output` 空のURLを出力します	ビルドが成功しなかった `--output-upload`、またはアーティファクトを生成する前に失敗した `outputUrl` 記録に追加される `null` ブランチで `[ -n "$URL" ]` 使用する前に
`build last-output` エラーが `Unsupported record schemaVersion`	ランナーは、記録を書き込んだものよりも古いCLIを実行しているため、プロデューサーとリーダーを同じ明示的なバージョンに固定する必要があります (例えば、 `bunx @capgo/cli@7.104.0 …` 両方の側で同じバージョンを使用するのではなく `@latest`、ジョブ間で漂うことができるもの

プラットフォーム固有のビルドエラーについては、トラブルシューティングガイド.

次のステップ

Auto OTA またはネイティブブランチ CI のライブアップロードと Capgo ビルドの間

CI UI からトリガー Actions タブから Capgo ビルドを実行

ビルドウェブホック管理画面のHTTPコールから同じワークフローを開始

クレデンシャルセットアップ iOSおよびAndroidの資格情報をBase64シークレットとして準備するための完全なリファレンス。

構成オプション CLIフラグと環境変数のすべての設定オプション