Push fixes to users in minutes, build signed iOS and Android apps without a Mac, and roll back in one click.

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

一般的なCapgo設定では、開発チャンネル運用チャンネル。CIはOTAバンドルを devにアップロードし、 production 日本語 --fail-on-incompatible CIは、CIでビルドされるlive updateが新しいネイティブcodeを必要とするものを間違って配信することができない。

Live Update Cloudflare Capacitor GitHub

Capgoのネイティブパッケージの比較の背景について知りたい場合は、まず codeCIブランチでOTA vs Capgo ビルドが自動的に選択される全CIブランチについては、 SDK.

CLI

このガイドは dev と production チャンネルはすでに存在します。必要に応じて作成してください:

npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app

チャンネル	誰が受け取るか	通常のアップロード
`dev`	内部/QAビルド	JSのCIプッシュ（および意図的なネイティブベースライン）
`production`	ストアユーザー	リリース用にアップロードまたはプロモートされる場合のみ

--fail-on-incompatible Live Updateは両チャネルでデフォルトの良い設定です。 毎日OTAのアップロード。アップロードしているバンドルのネイティブパッケージを、現在のチャンネルで公開されているバンドルと比較します。 チャンネルチャンネル

チャンネル

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible チャンネル --auto-min-update-version チャンネル metadata 戦略 (推奨の下記). チャンネルがまだない場合 metadata まだない場合は省略 --auto-min-update-version まだ変更されていない場合

オプションのCIゲート前アップロード:

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

意図的なネイティブブーム (フラグを一度だけ)

あなた cannot 新しいネイティブのcodeが必要なバンドルをアップロードする --fail-on-incompatibleアップロードすることができないバンドルが新しいネイティブ Capacitor を必要とする場合、Capacitor を維持することができます。そのフラグは、正確にそのケースをブロックするために存在します。プラグイン、Capacitor バージョン、または他のネイティブ依存関係が意図的に変更された場合:

Ship the matching ネイティブバイナリ App Store / Play Store または Capgo Capgo ビルド).
JS バンドルのアップロード without --fail-on-incompatible.
Prefer --auto-min-update-version チャンネルを有効にしながら metadata アップデートの戦略
新しいアプリをインストールするまで、古いバイナリ上のデバイスは新しいバンドルを受信しないようにするため --fail-on-incompatible そのベースラインアップロード後、通常のOTA CIに戻し --auto-min-update-version チャンネルが有効なまま metadata).

1回ごとにチャネルごとに: メタデータゲーティングを有効にする
ターミナルウィンドウ
```
npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata
```
上記のステップを繰り返す dev そのチャネルも意図的にネイティブのベースラインを受け取る場合。この切り替え後、チャネルにアップロードされるすべてのアップロードには --auto-min-update-version または --min-update-version.
チャネルにマッチしたOTAベースラインをアップロードする

これは、チャネルに新しいネイティブパッケージを記録します。その後
ネイティブバイナリを配信する --fail-on-incompatible)
ターミナルウィンドウ
```
npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --auto-min-update-version
```
このチャンネルに新しいネイティブパッケージが追加されます。 bundle releaseType / --fail-on-incompatible Baselineを使用します。
保護されたOTAアップロードを再開します。

次のJSのみリリースでは、両方のフラグを使用します。
ターミナルウィンドウ
```
npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version
```

よくある質問

Can I keep `--fail-on-incompatible` Native-incompatible bundle をまだ送信する必要がありますか。

Section titled “フラグを省略してアップロードするのは正解ですか？” --auto-min-update-version はい。新しいバイナリを出荷した後、チャンネルのネイティブ基準を進めるには、チャンネルのライブバンドルのネイティブパッケージと一致しないアップロードはフラグを残してください。そうしないと、CI で意図しないネイティブの漂流が失敗しない可能性があります。

まず

Yes. That is the supported way to advance the channel’s native baseline after you ship a new binary. Keep the flag on every other OTA upload so accidental native drift still fails CI.

Native OTA Channel Workflow Do I upload to Capgo? `dev` first, then `production`?

はい、もしそれがあなたのプロセスと一致する場合。同じルールを実行してください。 per チャンネル：互換性のチェックは、対象チャンネルにライブしているものに基づいて行われます。プロモーションまたは再アップロードは production only after dev looks good、 --fail-on-incompatibleと使用してください。各チャンネルに新しいネイティブパッケージを記録する必要がある場合は、

新しいネイティブバンドルをアップロードした場合、フラグがまだ有効なままです。

CI fails and Capgo does not ship that upload. That is the expected outcome. Either the change was accidental (fix the native packages and retry as OTA), or it was intentional (use the native path above).

どのフラグをどのジョブに付けるか

パス	状況	アップロードフラグ
OTA	JSのみ;ネイティブパッケージはチャンネルに合わせる	`--fail-on-incompatible` + `--auto-min-update-version` チャンネルがオンの場合に必要 `metadata`)
ネイティブベースライン	新しいネイティブバイナリ + マッチングのJSバンドル	なし `--fail-on-incompatible`;保持 `--auto-min-update-version`

ネイティブ互換性

CapgoはCapgoがネイティブパッケージの変化を検出するしくみと、デバイスにとって不相応とは何かについて説明します。

Auto OTA またはネイティブ

Wire bundle releaseType GitHubアクションまたはGitLabにワイヤーする

バージョン対象

CLI: バンドル

__CAPGO_KEEP_0__: バンドル

アップロード、互換性、releaseType、関連フラグのリファレンス

ネイティブ + OTA チャンネルワークフローから続ける Native + OTA チャネルワークフロー Live Updateをnativeリリース間で安全に保つには、接続する必要があります。 Native互換性パッケージ比較ルールのために Auto OTAまたはNative CIブランチングのためにバージョン目標設定ページ/エリア: Capgoのソリューションマーケティングページ。役割: セクションまたはページヘッダー。見られる場所: ソリューション/バージョン目標設定.astro。メッセージキー `solutions_version_targeting_title` (ソリューションバージョン目標設定タイトル)。 Capgo CLI バンドル参照メタデータフロア、そして