メインコンテンツへスキップ

コマンド

このページはガイド付きの概要です。正確なフラグは最新のコマンドリファレンスを参照してください: アプリ, バンドル, チャンネルや に作成してビルドします.

すべてのコマンドは、capacitor プロジェクトが正しく初期化されたアプリフォルダ内で実行してください。

npx @capgo/cli@latest init [apikey]

このメソッドは、ステップごとにオンボーディングするためのものです。

アプリをCapgoに追加します。更新を検証するためにcodeをアプリに追加します。同様に、アプリをビルドします。さらに、アプリをCapgoにアップロードします。そして、更新が正常に動作するか確認できるよう支援します。

npx @capgo/cli login [apikey]

このメソッドは、次を覚えておくためのものです apikey あなたの代わりに行います。

任意で以下を指定できます:

--local これはあなたの~を保存します APIキー ローカルリポジトリに配置し、git で無視するように設定します。

npx @capgo/cli doctor

Capgo パッケージが最新かどうかを確認するコマンドです。

このコマンドはバグレポートにも役立ちます。

npx @capgo/cli app add [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

💡 指定されていないオプションは、設定ファイルから推測されます。

任意で以下を指定できます:

  • --icon [/path/to/my/icon] Capgo web app でカスタムアイコンを表示するため
  • --name [test] リストにカスタム名を表示するため
  • --apikey [key] アカウントと連携するための API キー。
  • --retention [retention] app bundle の保持期間(日数)。デフォルトは 0(無制限)。

例: capacitor.config.json appId と AppName については、resources フォルダからアイコンが推測されます

{
"appId": "ee.forgr.capacitor_go",
"appName": "Capgo",
"webDir": "dist"
}

npx @capgo/cli app set [appId]

[appId] はアプリIDです。フォーマットについては こちら.

任意で以下を指定できます:

  • --icon [/path/to/my/icon] Capgo web app でカスタムアイコンを表示するため
  • --name [test] リストにカスタム名を表示するため
  • --retention [retention] app bundle の保持期間(日数)。デフォルトは 0(無制限)。
  • --expose-metadata [true|false] bundle のメタデータ(link と comment)をプラグインに公開するため
  • --preview または --no-preview bundle と channel のプレビュー用 QR コードを有効/無効にするため
  • --allow-device-custom-id または --no-allow-device-custom-id カスタムデバイスIDを制御するため
  • --block-provider-infra-requests または --no-block-provider-infra-requests 既知の Google および Apple データセンターからのリクエストのブロックを制御します。
  • --build-timeout-minutes [5-360] ネイティブビルドのタイムアウトを設定します。
  • --ios-store-url [url] または --android-store-url [url] ストア URL を設定します。
  • --default-upload-channel [channel] デフォルトのアップロードチャネルを設定します。
  • --default-download-channel [channel] デフォルトのダウンロードチャネルを設定するか、 --disable-download-channels すべてのダウンロードチャネルを非公開にします。
  • --apikey [key] アカウントと連携するための API キー。

npx @capgo/cli app list [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。

npx @capgo/cli app delete [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。
  • --bundle バージョン番号を指定すると、そのバージョンのみが削除されます。

npx @capgo/cli app debug [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。
  • --device デバッグ対象のデバイスを指定して

npx @capgo/cli app setting [path]

Capacitor の設定を編集します。

[path] - 変更したい設定のパス。例えば、 appId、指定してください appId. 自動更新を無効にする場合は、 capacitor-updater、指定してください plugins.CapacitorUpdater.autoUpdate を使用して --string off.

次のいずれかを必ず指定してください: --string または --bool!

オプション:

  • --string <string> - 設定を文字列に設定します
  • --bool <true | false> - 設定を boolean に設定します

アップロード

「Upload」セクション

npx @capgo/cli bundle upload [appId]

[appId] はアプリIDです。フォーマットについては こちら.

任意で以下を指定できます:

  • --apikey <apikey> アカウントと連携するための API キー。
  • --path <path> アップロードするフォルダのパス。
  • --channel <channel> リンク先のチャンネル。
  • --external <url> Capgo Cloudにアップロードする代わりに、外部URLにリンクします。
  • --iv-session-key <key> 外部bundle URL用のIVとセッションキーを設定します。
  • --s3-endpoint <s3Endpoint> S3エンドポイントのURL。delta uploadやexternalオプションでは使用できません。
  • --s3-region <region> S3バケットのリージョン。
  • --s3-apikey <apikey> S3エンドポイント用のAPIキー。
  • --s3-apisecret <apisecret> S3エンドポイント用の API シークレット。
  • --s3-bucket-name <bucketName> AWS S3バケットの名前。
  • --s3-port <port> S3エンドポイントのポート番号。
  • --no-s3-ssl S3アップロードのSSLを無効化します。
  • --key <key> 公開署名鍵のカスタムパス (v1システム)。
  • --key-data <keyData> 公開署名鍵 (v1システム)。
  • --key-v2 <key> 秘密署名鍵のカスタムパス (v2システム)。
  • --key-data-v2 <keyData> 秘密署名鍵 (v2システム)。
  • --bundle-url bundleのURLをstdoutに出力します。
  • --no-key 署名鍵を無視して、未署名のupdateを送信します。
  • --no-code-check ソースの code で notifyAppReady() が呼ばれているか、およびルートフォルダにindexが存在するかのチェックをスキップします。
  • --display-iv-session updateの暗号化に使用されたIVとセッションキーをコンソールに表示します。
  • --bundle <bundle> アップロードするbundleのバージョン番号。
  • --auto-bump [level] channelにリンクされたbundleから自動インクリメント。なければ最新のリモートアプリバージョンを使用。Level: major, minor (デフォルト)、 patch (エイリアス fix), metadata、または ai (Workers AIがローカルファイルと前回のCapgo/channelの差分マニフェストを比較してLevelを推論し、短い理由をログに出力します。AIをスキップしてインクリメント patch 前回のCapgoバージョンがない場合)。空き名が見つかるまでインクリメントします(削除された名前は使用済みのままです)。以下とは併用できません: --bundle.
  • --min-update-version <minUpdateVersion> このバージョンにアップデートするために必要な最小バージョン。channelでdisable auto updateがmetadataに設定されている場合のみ使用されます。
  • --auto-min-update-version ネイティブパッケージに基づいて最小アップデートバージョンを設定します。
  • --ignore-metadata-check アップロード時のmetadata (node_modules) チェックを無視します。
  • --ignore-checksum-check アップロード時のチェックサムチェックを無視します。
  • --timeout <timeout> アップロード処理のタイムアウト(秒)。
  • --delta フルbundleと一緒にDelta (manifest) ファイルをアップロードします。
  • --delta-only フルbundleをスキップし、Delta (manifest) アップデートのみをアップロードします。
  • --no-delta Delta (manifest) のアップロードを無効にします(instant apply autoUpdate が有効な状態でフルbundleを使いたい場合に便利です)。
  • --tus tusプロトコルでbundleをアップロードします。
  • --multipart multipartプロトコルでS3にデータをアップロードします(非推奨。代わりにTUSを使用してください)。
  • --encrypted-checksum <encryptedChecksum> 暗号化されたチェックサム(署名)。外部bundleをアップロードする場合にのみ使用します。
  • --package-json <packageJson> package.jsonへのパス。モノレポで便利です。
  • --auto-set-bundle capacitor.config.jsonでbundleを設定します。
  • --node-modules <nodeModules> node_modules へのパスのリスト。モノレポで便利です(カンマ区切り、例: ../../node_modules,./node_modules)

⭐️ Externalオプションは、プライバシーを重視してcodeを第三者に送信したくない企業と、200 MBを超えるアプリという2つのケースに対応できます。この設定では、Capgoはzipへのリンクのみを保存し、そのリンクをすべてのアプリに送信します。

👀 Capgo cloudは、externalオプションの場合はリンクの中身を、保存時のcodeの中身も一切見ることはありません。

🔑 暗号化を使用することでセキュリティの第二の層を追加でき、Capgo は内容の閲覧や変更ができなくなります(「トラストレス」化)。

例: package.json バージョン

{
"version": "1.0.2"
}

⛔ バージョンは「0.0.0」より大きい必要があります。

💡 送信するたびにバージョン番号を更新してください。セキュリティ上の理由から、バージョン番号は上書きや削除後の再利用ができません。

npx @capgo/cli bundle list [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。

npx @capgo/cli bundle delete [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。
  • --bundle バージョン番号を指定すると、そのバージョンのみが削除されます。

クリーンアップ

「Cleanup」セクション

メジャーバージョンのSemVer範囲でCloudに

npx @capgo/cli bundle cleanup [appId] --bundle=[majorVersion] --keep=[numberToKeep]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。
  • --bundle [majorVersion] 以前のパッケージを削除する対象のバージョンです。最後の1つ + 指定数が保持されます。 numberToKeep.
  • --keep [numberToKeep] 保持するパッケージ数(デフォルト: 4)。

例:10.0.1 から 10.0.11 まで 10 個のバージョンがあり、次を使うと npx @capgo/cli cleanup [appId] --bundle=10.0.0 10.0.1 から 10.0.6 が削除されます。10.0.7 から 10.0.11 は保持されます。

合計 20 個のバージョンがあり、以下のように bundle 番号を指定しなかった場合: npx @capgo/cli cleanup [appId] --keep=2 18 個のバージョンが削除され、最後の 2 個が保持されます。

このコマンドは確認を求め、保持されるものと削除されるものをテーブルで表示します。

警告: このコマンドは非推奨で、次のメジャーリリースで削除されます。新しい暗号化システムを使用してください。 npx @capgo/cli bundle encrypt [path/to/zip]

このコマンドは、codeを外部ソースに保存する場合や、テスト目的で使用します。

任意で以下を指定できます:

--key [/path/to/my/private_key] 秘密鍵のパス。 --key-data [privateKey] インラインで使用する場合の秘密鍵データ。 コマンドはあなたの ivSessionKeyy と暗号化されたzipを生成します。uploadコマンドやdecryptコマンドで使用できます。

npx @capgo/cli bundle encrypt [path/to/zip] [checksum]

このコマンドは、外部ソースにcodeを保存する場合や、テスト目的で使用する場合に利用します。 チェックサムはバンドルのsha256値(—key-v2によって生成)であり、復号後のファイルの完全性を検証するために使用されます。 秘密鍵で暗号化され、バンドルとともに送信されます。 暗号化v2では、チェックサムがバンドルの「署名」にアップグレードされます。

任意で以下を指定できます:

--key [/path/to/my/private_key] 秘密鍵のパス。 --key-data [privateKey] インラインで使用する場合の秘密鍵データ。 --json 情報をJSON形式で出力します。 コマンドはあなたの ivSessionKeyy と暗号化されたzipを生成します。uploadコマンドやdecryptコマンドで使用できます。

npx @capgo/cli bundle decrypt [path/to/zip] [ivSessionKey]

任意で以下を指定できます:

--key [/path/to/my/private_key] 秘密鍵のパス。

--key-data [privateKey] インラインで使用する場合の秘密鍵データです。このコマンドは主にテスト用で、zipを復号し、復号されたbase64形式のセッションキーをコンソールに出力します。

npx @capgo/cli bundle decryptV2 [path/to/zip] [ivSessionKey]

任意で以下を指定できます:

--key [/path/to/my/private_key] 秘密鍵のパス。 --key-data [privateKey] インラインで使用する場合の秘密鍵データです。このコマンドは主にテスト用で、zipを復号し、復号されたbase64形式のセッションキーをコンソールに出力します。 --checksum [checksum] ファイルのチェックサム。復号後にチェックサムを検証します。

npx @capgo/cli bundle zip [appId]

[appId] はアプリIDです。フォーマットについては こちら.

任意で以下を指定できます:

  • --path [/path/to/my/bundle] 特定のフォルダをアップロードします。
  • --bundle [1.0.0] ファイル名のbundleバージョン番号を設定します。
  • --name [myapp] ファイル名をオーバーライドします。
  • --json 情報をJSON形式で出力します。
  • --no-code-check codeのチェックを無視してbundleを送信します。
  • --key-v2 新しい暗号化システムを使用します。新しい暗号化システムはファイルの整合性を検証するためにより優れたチェックサムを使用するため、必須です。

npx @capgo/cli bundle compatibility [appId] -c [channelName]

[appId] はアプリIDです。フォーマットについては こちら. [channelName] 確認するチャンネル名。

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。
  • --text テーブルでは絵文字の代わりにテキストを使用してください
  • --channel [channel] 互換性を確認する対象のチャンネル。
  • --package-json <packageJson> package.json へのパス。モノレポで便利です。
  • --node-modules <nodeModules> node_modules へのパスのリスト。モノレポで便利です(カンマ区切り、例: ../../node_modules,./node_modules)

npx @capgo/cli channel add [channelName] [appId]

[channelName] 新しいチャンネル名(例: production または beta. [appId] アプリIDの形式 com.test.app について説明します こちら.

npx @capgo/cli channel delete [channelName] [appId]

[channelName] 削除するチャンネルの名前。 [appId] アプリIDの形式 com.test.app について説明します こちら.

npx @capgo/cli channel list [appId]

[appId] アプリIDの形式 com.test.app について説明します こちら.

任意で以下を指定できます:

  • --apikey [key] アカウントと連携するための API キー。

npx @capgo/cli channel set [channelName] [appId]

[appId] はアプリIDです。フォーマットについては こちら. [channelName] 設定したいチャンネル名(例: production または beta.

任意で以下を指定できます:

  • --bundle [1.2.3] クラウドに送信済みのアプリ bundle をチャンネルに紐付けます。
  • --latest bundle のバージョンを取得する package.json:version、とは併用できません --bundle.
  • --state [ normal | default ] チャネルの状態を設定します。値は normal または default。1つのチャネルが default.
  • --downgrade チャネルがデバイスへダウングレードバージョンを送信できるようにします。
  • --no-downgrade チャネルがデバイスへダウングレードバージョンを送信することを禁止します。
  • --upgrade チャネルがデバイスへアップグレード(メジャー)バージョンを送信できるようにします。
  • --no-upgrade チャネルがデバイスへアップグレード(メジャー)バージョンを送信することを禁止します。
  • --ios チャネルがiOSデバイスへバージョンを送信できるようにします。
  • --no-ios チャネルがiOSデバイスへバージョンを送信することを禁止します。
  • --android チャンネルが Android デバイスにバージョンを送信することを許可します。
  • --no-android チャンネルが Android デバイスにバージョンを送信することを禁止します。
  • --self-assign デバイスがこのチャンネルに自動割り当てされることを許可します。
  • --no-self-assign このチャンネルへのデバイスの自己割り当てを禁止します。
  • --disable-auto-update STRATEGY このチャンネルの自動更新戦略を無効にします。オプション: major, minor, patch, metadata, none。
  • --apikey [key] アカウントと連携するための API キー。

アップデートを無効化する戦略

「更新戦略の無効化」セクション

古いバージョンの更新を無効にする方法はいくつかあります。
Capgo はネイティブ code を更新できないため、古いネイティブ code のバージョンから、更新されたネイティブ code のバージョンへの更新は不可能であるべきです。 これを実現する方法はいくつかあります。

まず、 major 戦略。ネイティブベースラインからの更新を防止します 0.0.0 -> ターゲットバンドル 1.0.0。major はハイライトされた数字です (1.0.0 と 0.0.0).
2つ目は minor 戦略です。ターゲットbundleのメジャーまたはマイナーがデバイスのネイティブベースラインと異なる場合、アップデートを防ぎます。たとえば、 0.0.0 -> 1.1.0 または 1.1.0 -> 1.2.0.

第三に、 patch 戦略です。これは非常に厳格なモードとして capgo に追加されました。仕組みを完全に理解していない限り、使用は推奨されません。 アップデートを受け入れるには、次の条件を満たす必要があります:

  • ターゲットbundleとメジャーバージョンが同じであること、および version_build
  • ターゲットbundleとマイナーバージョンが同じであること、および version_build
  • ターゲットbundleとパッチバージョンが同じであること、および version_build
  • バージョンサフィックスのみ異なってよく、たとえばプレリリース (-beta.2) やビルドメタデータ (+build.2)

アップデートが許可または拒否されるシナリオの例を次に示します。

  • 1.0.0-beta.1 -> 1.0.0-beta.2 は許可
  • 1.0.0+build.1 -> 1.0.0+build.2 は許可
  • 1.0.0 -> 1.0.1 はブロック
  • 1.0.0 -> 1.1.0 はブロック
  • 1.0.0 -> 2.0.0 はブロック

戦略の比較には、ネイティブベースラインがとして送信されます version_build。現在ダウンロード済みのbundleとして送信されるものではありません version_name.

最後に、最も複雑な戦略です。 metadata 戦略。
有効化直後は、更新が 必ず 失敗します。チャンネルに必要なメタデータが不足しているためです。
チャンネルにメタデータが不足している場合、次のようなメッセージが表示されます:

メタデータが見つかりません

このようなエラーが表示された場合、失敗したチャネルの現在のバンドルに移動して、メタデータを設定する必要があります。
まず、どのチャネルで失敗しているかを確認します。 misconfigured 列

設定が誤っているテーブル

次に、失敗したチャネルに移動して Bundle numberをクリックします。バンドルページに移動するはずです。

失敗したチャネルを特定する

そこに着いたら Minimal update version フィールドを入力します。これは semver.
semver 以外の値を渡すとエラーになりますが、正常に処理されると、次のような表示になるはずです:

最小バージョンを設定

おそらく、更新のたびにこのデータを手動で設定したくないはずです。幸いなことに、CLI は、このメタデータなしで更新を送信することを防止します。

CLI メタデータなしで失敗

を使用する場合、バンドルを正しくアップロードするには metadata オプションに --min-update-version を使用して、 有効な semverを渡す必要があります。例えば、以下のようにします:

CLI メタデータ付きでアップロード

この --min-update-version 互換性を確保する唯一の方法ではありません。 他にも --auto-min-update-versionがあります。その仕組みは以下の通りです。

まず、チャネルにアップロードされている現在のバージョンを確認します。互換性のチェックは bundle compatibility コマンドと同様に行われます。 次に、新しいバージョンが100%互換性がある場合、チャネルの最新バージョンの min_update_version を再利用します。 そうでない場合、 min_update_version を新しくアップロードされたバージョンのバンドル番号に設定します。

このオプションを使用すると、常に min_update_version に関する情報が表示されます。表示は次のようになります:

最小更新バージョン

新しいバージョンが互換性がない場合、表示は次のようになります

最小更新バージョンが互換性なし

エンドツーエンド暗号化 (Trustless)

セクション「エンドツーエンド暗号化 (Trustless)」

Capgo はエンドツーエンド暗号化をサポートしています。これは、バンドル(code)がクラウドに送信される前に暗号化され、デバイス上で復号化されることを意味します。そのためにRSA鍵ペアを生成する必要があります。以下のコマンドを使用して生成できます。

暗号化システムはRSAとAESの組み合わせです。RSA鍵はAES鍵を暗号化するために使用され、AES鍵はファイルを暗号化するために使用されます。

暗号化システムの詳細については、以下を参照してください。

暗号化の仕組み

暗号化スキーマ

npx @capgo/cli key create

任意で以下を指定できます: --force 既存の鍵を上書きするために使用します。このコマンドを実行すると、アプリ内に鍵ペアが作成され、秘密鍵を安全な場所に保存するよう促されます。秘密鍵をgit commitに含めたり、誰かと共有したりしないことをお勧めします。

ローカルでのテスト後、設定ファイルから鍵を削除し、CIステップに追加してください。 key save

npx @capgo/cli key save

任意で以下を指定できます:

--key [/path/to/my/public_key] 公開鍵ファイルのパス。

--key-data [publicKey] インラインで使う場合の公開鍵データ。推奨どおりアプリ設定にキーをコミットしていない場合に、このコマンドが役立ちます。

作業を自動化するには、GitHub アクションにサーバーへのプッシュを任せるのがおすすめです。

GitHub アクションのチュートリアル

GitHub - Cap-go/demo-app

CI 環境変数に API キーを設定するのを忘れないでください。

使用している場合 コマンド ダッシュボードと API の運用を計画するには、これを次と連携させます API の概要 「API の概要」の実装の詳細については、 はじめに 「はじめに」における実装の詳細については、 API キー API Keys の実装の詳細については、 デバイス Devices の実装詳細については、および Bundle Bundlesの実装詳細については