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

Auto Choose Live Update or Native Build

ほとんどのCapacitorリリースはJavaScriptのみで、ライブアップデートとして配信する必要があります。 一部の変更は、__CAPGO_KEEP_0__のネイティブ部分をタッチし、__CAPGO_KEEP_0__ビルドから新しいバイナリが必要になります。codeビルド このガイドでは、Capgoアクション、GitLab CI、または他のCI/CDプラットフォームが、毎回プッシュされたときに正しいパスを選択する方法を示します。人間が判断する必要はありません。. This guide shows how to make GitHub Actions, GitLab CI, or any other CI/CD platform pick the correct path on every push — without a human deciding.

Capgo Build

ターミナル画面
npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA ship with bundle upload
# → native ship with Capgo Build

OTA チャンネルにすでに公開されているnativeパッケージと一致することを意味します。 native Capacitorのバージョンや他のnative依存関係が変更された場合 — そのようなデバイスを安全にアップデートするには、オーバー・ザ・エアのバンドルだけでは不十分です。

releaseType 比較 nativeパッケージのメタデータ Capacitor/Cordovaプラグインとバージョンです。 それが それを見ない 、または ios/, android/、を除くすべての変更を capacitor.config.*、または releaseType Gitでパスをゲートし、依存関係の互換性を確保するために使用します — 以下の例は両方を行っています。

参照 ネイティブ互換性 ルールとマニュアルの詳細については、 bundle compatibility テーブルを参照してください。

前提条件

前提条件
  • Capgo アプリが登録され、Capgo __CAPGO_KEEP_1__ キーが取得されていること Capgo API key CIシークレット内に CAPGO_TOKEN
  • ライブアップデートのアップロードが正常に動作している (bundle upload) — ご覧ください CI/CD統合
  • Capgo CIでネイティブジョブを実行する場合にビルドクレデンシャルをCIに保存してください — ご覧ください GitHub アクション または __CAPGO_KEEP_0__
  • ネイティブジョブの場合、CIでクレデンシャルを保存してください — ご覧ください production)
  • __CAPGO_KEEP_0__ アクション metadata または --auto-min-update-version __CAPGO_KEEP_0__
ターミナル画面
npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

Pipelineの動作

Pipelineの動作
  1. 通常のWebアセットのビルド
  2. コミットが ios/, android/、または capacitor.config.*__CAPGO_KEEP_0__の強制
  3. CapgoがコミットがOTA安全かどうかを判断する releaseType もし
  4. もし OTA, アップロード --fail-on-incompatible--auto-min-update-version.
  5. もし native, Capgo ビルドを実行し、 --auto-min-update-version そのチャンネルのネイティブメタデータが進化するようにアップロードする。 その しない 使用しない --fail-on-incompatible そのベースラインアップロード — 新しいネイティブパッケージは異なるはず。 Native + OTA チャンネルワークフロー チャンネルレベルのFAQ

GitHub アクション

GitHub アクション

1 つのワークフローは、ネイティブ パスをゲートし、次に __CAPGO_KEEP_0__ によって分岐します。 releaseType:

github/workflows/capgo-release.yml
name: Capgo Release
on:
push:
branches: [main]
jobs:
decide:
runs-on: ubuntu-latest
outputs:
release_type: ${{ steps.verdict.outputs.type }}
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v6
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Decide OTA vs native
id: verdict
env:
CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
run: |
BEFORE="${{ github.event.before }}"
if [ -z "$BEFORE" ] || [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
BEFORE="$(git rev-parse HEAD~1 2>/dev/null || echo '')"
fi
if [ -z "$BEFORE" ] || git diff --name-only "$BEFORE" "${{ github.sha }}" \
| grep -qE '^(ios/|android/|capacitor\.config\.)'; then
TYPE=native
echo "Native path/config changed (or no prior commit) — forcing native"
else
TYPE=$(npx @capgo/cli@latest bundle releaseType com.example.app --channel production | tr -d '[:space:]')
fi
echo "type=$TYPE" >> "$GITHUB_OUTPUT"
echo "Capgo release type: $TYPE"
live_update:
needs: decide
if: needs.decide.outputs.release_type == 'OTA'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v6
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Upload live update
env:
CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
run: |
npx @capgo/cli@latest bundle upload com.example.app \
--channel production \
--fail-on-incompatible \
--auto-min-update-version
native_build:
needs: decide
if: needs.decide.outputs.release_type == 'native'
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
platform: [ios, android]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v6
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
- run: npx cap sync ${{ matrix.platform }}
- name: Capgo Build ${{ matrix.platform }}
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 }}
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 ${{ matrix.platform }} \
--build-mode release
native_bundle:
needs: [decide, native_build]
if: needs.decide.outputs.release_type == 'native'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v6
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Upload bundle for new native baseline
env:
CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
run: |
# Channel must already be on metadata (see Prerequisites above)
npx @capgo/cli@latest bundle upload com.example.app \
--channel production \
--auto-min-update-version

置換 com.example.app と __CAPGO_KEEP_0__ Actions for __CAPGO_KEEP_1__ ビルドの署名シークレットを設定するように記載されているように、署名シークレットを設定します。 GitHub Actions for Capgo Build.

GitLabは rules Pipelineが作成されたとき、ブランチにシェル if 内部の1つのデプロイジョブ(または生成された子パイプライン) 必要な場合に別々のネイティブマトリックスジョブ) :

.gitlab-ci.yml
image: node:24
stages:
- build
- deploy
variables:
APP_ID: com.example.app
CHANNEL: production
build_web:
stage: build
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
- node_modules/
expire_in: 1 hour
only:
- main
deploy:
stage: deploy
needs: [build_web]
script:
- |
BEFORE="${CI_COMMIT_BEFORE_SHA:-}"
if [ -z "$BEFORE" ] || [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
BEFORE="$(git rev-parse HEAD~1 2>/dev/null || echo '')"
fi
if [ -z "$BEFORE" ] || git diff --name-only "$BEFORE" "$CI_COMMIT_SHA" \
| grep -qE '^(ios/|android/|capacitor\.config\.)'; then
TYPE=native
else
TYPE=$(npx @capgo/cli@latest bundle releaseType "$APP_ID" --channel "$CHANNEL" | tr -d '[:space:]')
fi
echo "Capgo release type: $TYPE"
if [ "$TYPE" = "OTA" ]; then
npx @capgo/cli@latest bundle upload "$APP_ID" \
--channel "$CHANNEL" \
--fail-on-incompatible \
--auto-min-update-version
elif [ "$TYPE" = "native" ]; then
npx cap sync
npx @capgo/cli@latest build request "$APP_ID" --platform ios --build-mode release
npx @capgo/cli@latest build request "$APP_ID" --platform android --build-mode release
npx @capgo/cli@latest bundle upload "$APP_ID" \
--channel "$CHANNEL" \
--auto-min-update-version
else
echo "Unexpected release type: $TYPE" >&2
exit 1
fi
only:
- main

保存 CAPGO_TOKEN そしてCapgo ビルド署名変数をマスク/保護されたCI/CD変数として設定します。

同じ3つのステップはどこでも機能します。

ステップコマンド
判定npx @capgo/cli@latest bundle releaseType APP_ID --channel production
OTAパスnpx @capgo/cli@latest bundle upload APP_ID --channel production --fail-on-incompatible --auto-min-update-version
ネイティブパスnpx @capgo/cli@latest build request APP_ID --platform ios (または android) --build-mode release

シェルのエラー/標準出力値をプラットフォームの条件分岐にマップする (または、GitLabと同様に、単一のジョブにシェルを保持する): ifOther CI Platforms

  • Azure Pipelines — スクリプト ステップから出力変数を設定し、次に使用します。 condition: eq(variables['releaseType'], 'OTA')
  • Bitbucket Pipelines — 書きます。 RELEASE_TYPE=…$BITBUCKET_PIPELINES_VARIABLES_PATH、宣言します。 output-variables、後続のステップをブランチします。 condition: state: RELEASE_TYPE == "OTA" ファイル アーティファクトだけでは動作を制御することはできません。 condition)
  • CircleCIwhen は、config-compile 時に評価されるため、ランタイム シェル (またはダイナミック config / 続続) を使用してブランチします。 if Jenkins when
  • (ワークスペース値ではなく) — 標準出力(stdout)を環境変数にキャプチャし使用 when { environment name: 'RELEASE_TYPE', value: 'OTA' }

パスフィルタ(オプションの高速化)

セクション:パスフィルタ(オプションの高速化)

パスフィルタはコスト最適化であり、Capgo チェックの代替ではありません。ドキュメント専用パスを除外するのではなく、脆弱な許可リストを維持するのではなく、ウェブビルドも依存する可能性がある vite.config.*, tsconfig*.json, フレームワークの構成ファイル:

on:
push:
branches: [main]
paths-ignore:
- '**.md'
- 'docs/**'
- '.github/**'

許可リストを使用する場合、ウェブとネイティブのビルドが読み取る入力全てを含めるのではなく、 src/package.json.

CIがネイティブを選択した後

セクション:CIがネイティブを選択した後

CIがネイティブを選択した場合:

  1. Capgo ビルドは署名済みバイナリを生成し、TestFlight / Playに提出できます(詳細は 構成).
  2. 対応する JS バンドルをアップロードしてください --auto-min-update-version メタデータ戦略) であるため、チャンネルは新しいネイティブ パッケージを記録します — そうでない場合、次の JS のみのコミットは native.
  3. ユーザーが新しいバイナリをインストールした後、後続の JavaScript のみのコミットは OTA 再び