メインコンテンツにジャンプする

GitHub アクション

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

何が得られるか

何が得られるか

手動でないリリース

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

ローカルセットアップなし

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

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

シークレットはGitHubリポジトリのシークレット内に保存され、リポジトリとワークフロー実行者だけがアクセスできるようになっています。ローテーションや監査も簡単です。

並列ビルド

iOSとAndroidを同時にビルドすることができます。マトリックスジョブを使用すると、通常のリリースは10分以内に完了します。

Capgoアカウントと有効なサブスクリプションが必要です。

  • A Capgo account with an active subscription and a Capgo API key
  • Your app registered in Capgo (bunx @capgo/cli@latest app add __CAPGO_KEEP_0__
  • ローカルに設定した資格情報を構築します。 bunx @capgo/cli@latest build init — 以下を参照してください。 資格情報の管理 ワークショップのガイドを参照してください。
  • ローカルビルドが成功した場合 (bunx @capgo/cli@latest build request com.example.app --platform android --build-mode debugローカルビルドが成功した場合 (
  • CIは最初のビルドをデバッグする場所ではありません。 GitHub CLI (gh) __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ (gh auth login)

セットアップ

セットアップ

The Capgo CLI can export your local credentials as a ready-to-use .env ローカル認証情報をエクスポートすることができます。 gh secret set -fファイルとして。

  1. Add your Capgo API key as a repository secret

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

    __CAPGO_KEEP_0__キーはアプリごとの認証情報ストアの一部ではないので、手動で一度追加してください:
    gh secret set CAPGO_TOKEN --body "your_capgo_api_key_here"

    クリップボードにコピー Capgoダッシュボードでキーを生成 GitHub Actionsとともに アップロード 権限が高い

  2. 環境変数をファイルにエクスポートする .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 の環境変数名は分離されているため、組み合わせることは競合しない。

  3. ファイルを __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. Verify with gh secret list.

  4. ワークフロー ファイルを作成

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

どのようにビルドをトリガーしたいかによって、以下の 3 つのトリガー パターンを選択してください。

シークレット セクション

「シークレット セクション」のタイトル gh secret set -f 参考として、

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

必要なことは何も覚えずに済む — 以下のワークフロー例はすべてのものを参照している。

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

誰でも書き込み権限がある人は、ビルドをトリガーできる アクション GitHubのタブにプラットフォームのドロップダウンがあります。アドホックのテストビルドやリリースのトリガーに便利です。

github/ワークフローズ/capgo-ビルドマニュアル.yml
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 リリースコマンドになります。

github/workflows/capgo-build-release.yml
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. メインブランチにプッシュしたときにデバッグビルド

セクションのタイトル “3. メインへのプッシュ時にデバッグビルド”

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

github/workflows/capgo-build-main.yml
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 共通のパターン

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

Section titled “Common Patterns”

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

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

テストビルドの場合、ストアの提出をスキップします: Android は --no-playstore-uploadiOS の場合、 --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コードを読みます: 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タグなどの値を制御するには、次のようにパスを渡してください。

クリップボードにコピー

section --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 実行されていません、または実行されたのは別のリポジトリです。Verify with gh secret list
cap sync CI で失敗しますが、ローカルでは正常に動作しますA native plugin が存在しない package.json、または忘れていた bun installcap sync
アプリが正常にビルドされたが、App Store Connect に表示されないチーム ID が間違っている、または App Store Connect にアプリのレコードがまだ存在していない。ローカルで確認するには bunx @capgo/cli@latest build credentials manage
アップロード中 "プロジェクト" がハングするプロジェクト アーカイブが通常より大きい — これがアップロードされていないことを確認する node_modules アップロードされていない (デフォルトではアップロードされないはず)
Provisioning profile doesn't match bundle IDプロビジョニング マップが Xcode が署名する bundle ID と異なる ID を指している。プロファイルを再読み込みし、再エクスポートする build init ローカルで資格情報が変更されたが、CI が失敗する build credentials manage
再エクスポートし、再プッシュすることを忘れないでくださいre-export and re-push を実行する bunx @capgo/cli@latest build credentials managegh secret set -f .env.capgo.<appId>
マネージャーは組み合わせファイルを書き込まないプラットフォーム間で共有設定キーが異なる場合、マネージャーは警告を出し確認を求める。確認すると上書き勝ち、またはプラットフォームごとに再エクスポートする --platform ios / --platform android
build last-output URLが空白になるビルドが失敗した --output-upload、またはアーティファクトを生成する前に失敗した outputUrl レコードに追加される null 使用する前に枝分かれする [ -n "$URL" ] エラーが発生する
build last-output レコードを書き込んだマネージャーが古い__CAPGO_KEEP_0__であるため、プロデューサーとリーダーを同じ明示的なバージョンに固定する (例えば Unsupported record schemaVersionThe runner is on an older CLI than the one that wrote the record. Pin both producer and reader to the same explicit version (e.g. bunx @capgo/cli@7.104.0 … 、どちらかが浮動しジョブ間で漂う @latest, which floats and can drift between jobs

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