命令

复制一个包含安装步骤和本插件的完整 Markdown 指南的配置提示。

使用

所有命令应在您的应用程序文件夹中运行，capacitor 项目已正确点亮。

Capacitor：适用于 Web 应用程序的跨平台原生运行时

初始化

npx @capgo/cli@latest init [apikey]

此方法旨在一步一步地引导您。

它将添加您的应用程序到 Capgo。它将添加 code 到您的应用程序以验证更新。同样，它将构建您的应用程序。另外，它将上传您的应用程序到 Capgo。此外，它将帮助您检查更新是否有效。

npx @capgo/cli login [apikey]

此方法旨在记住您的登录信息 apikey 为您提供服务。

可选地，您可以提供：

--local 将您的 apikey 存储在本地仓库中并将其添加到.gitignore中。

医生

npx @capgo/cli doctor

检查是否已更新为Capgo包的命令

这个命令也会对bug报告有所帮助。

App

Add

npx @capgo/cli app add [appId]

[appId] 您的应用ID的格式 com.test.app 如上所述在这里.

💡 如果没有提供选项，所有选项都会在您的配置中被猜测。

您可以选择：

--icon [/path/to/my/icon] 以自定义图标显示在Capgo web应用中
--name [test] 以自定义名称显示在列表中
--apikey [key] API key 链接到您的账户。
--retention [retention] 应用程序包的保留期限（天），默认值为 0，即无限期。

例如 capacitor.config.json appId 和 AppName 的值，图标将在资源文件夹中猜测

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

设置

npx @capgo/cli app set [appId]

[appId] 这是您的应用 ID，格式解释请参阅.

您可以选择提供：

--icon [/path/to/my/icon] 以自定义图标显示在 Capgo 网站应用中
--name [test] 以自定义名称显示在列表中
--retention [retention] 应用程序包的保留期限（天），默认值为0，即无限期。
--apikey [key] API用于链接到您的帐户。

列表

npx @capgo/cli app list [appId]

[appId] 您的应用程序ID的格式 com.test.app 如上所述您可以提供：.

__CAPGO_KEEP_0__用于链接到您的帐户。

--apikey [key] API key to link to your account.

标题为“删除”的部分

npx @capgo/cli app delete [appId]

[appId] 如上所述 com.test.app 在这里解释在这里.

您可以选择提供：

--apikey [key] API关键字以链接到您的帐户。
--bundle 带有版本号的只会删除该版本。

Debug

npx @capgo/cli app debug [appId]

[appId] 您的应用ID的格式 com.test.app 在这里解释在这里.

您可以选择提供：

--apikey [key] API关键字以链接到您的帐户。
--device With __CAPGO_KEEP_0__ 设备进行调试

设置

npx @capgo/cli app setting [path]

编辑 Capacitor 配置。

[path] - 你想改变的设置路径。例如，要改变 appId, 提供 appId. 如果你想禁用自动更新功能，请 capacitor-updater, 提供 plugins.CapacitorUpdater.autoUpdate 与 --string off.

你必须提供 --string 或 --bool!

选项：

--string <string> - 将设置设为一个字符串
--bool <true | false> - 将设置设为一个布尔值

Bundle

Upload

npx @capgo/cli bundle upload [appId]

[appId] 是您的应用ID，格式解释在这里.

您可以选择给出：

--apikey <apikey> API 键来链接到您的帐户.
--path <path> 上传文件夹的路径
--channel <channel> 链接到频道
--external <url> 将链接指向外部 URL 而不是上传到 Capgo 云。
--iv-session-key <key> 设置捆绑 URL外部的 IV 和会话密钥。
--s3-endpoint <s3Endpoint> S3 端点的 URL。不支持 delta 上传或外部选项。
--s3-region <region> 您的 S3 存储桶的区域。
--s3-apikey <apikey> API 键为您的 S3 端点。
--s3-apisecret <apisecret> API 密钥为您的 S3 端点。
--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 将打包 URL 打印到标准输出.
--no-key 忽略签名密钥并发送清晰的更新.
--no-code-check 忽略检查源 code 和索引是否在根目录中调用 notifyAppReady() 是否存在.
--display-iv-session 在控制台显示用于加密更新的 IV 和会话密钥.
--bundle <bundle> 要上传的打包的版本号.
--min-update-version <minUpdateVersion> 仅当禁用自动更新设置为元数据时，用于更新到此版本所需的最小版本号.
--auto-min-update-version 基于本机包设置最小更新版本.
--ignore-metadata-check 在上传时忽略元数据 (node_modules) 检查.
--ignore-checksum-check 在上传时忽略校验和检查.
--timeout <timeout> 上传过程超时时间（以秒为单位）。
--delta 上传 Delta (清单) 文件并行上传完整打包文件.
--delta-only 仅上传 Delta (清单) 更新，跳过完整的捆绑包。
--no-delta 禁用 Delta (清单) 上传（如果启用了即时应用模式但您想上传完整的捆绑包）。 autoUpdate 使用 tus 协议上传捆绑包。
--tus 使用多部分协议上传数据到 S3，已过时，请使用 TUS 代替。
--multipart 用于上传外部捆绑包的加密校验和（签名）。
--encrypted-checksum <encryptedChecksum> 用于 monorepos 的 package.json 路径。
--package-json <packageJson> 在 __CAPGO_KEEP_0__.config.json 中设置捆绑包。
--auto-set-bundle Set the bundle in capacitor.config.json.
--node-modules <nodeModules> ⭐️ 外部选项可以解锁 2 个案例：企业有隐私担忧，不向第三方发送 __CAPGO_KEEP_0__，并且应用大小超过 200 MB。使用此设置，__CAPGO_KEEP_1__ 只会存储 zip 链接并将链接发送给所有应用。

👀 code 云服务不会查看链接中的内容（对于外部选项），或在 Capgo 中存储的内容。

👀 Capgo cloud never looks at what is in the link (for external option), or in the code when stored.

Capgo

Example of package.json 用于版本

{
  "version": "1.0.2"
}

⛔ 版本应大于“0.0.0”。

💡 每次发送时，请记得更新版本号，版本号不能被覆盖或重复使用，否则会影响安全性。

列表

npx @capgo/cli bundle list [appId]

[appId] 您的应用 ID 格式 com.test.app 如图所示您可以选择提供：.

__CAPGO_KEEP_0__ 键用于链接到您的帐户。

--apikey [key] API key to link to your account.

删除

npx @capgo/cli bundle delete [appId]

[appId] 你的应用 ID 格式 com.test.app 如图所示在这里.

如果需要，你可以提供：

--apikey [key] API 键来链接到你的账户
--bundle 带有版本号的只会删除这个版本

清理

在 SemVer 范围内清理一个大版本的

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

[appId] 你的应用 ID 格式 com.test.app 在这里解释在这里.

您可以提供：

--apikey [key] API 键来链接到您的帐户
--bundle [majorVersion] 您希望删除之前的包的版本号，它将保留最后一个 + numberToKeep.
--keep [numberToKeep] 您希望保留的包数量（默认值为 4）。

例如：如果您有 10 个版本，从 10.0.1 到 10.0.11，使用 npx @capgo/cli cleanup [appId] --bundle=10.0.0 它将删除 10.0.1 到 10.0.6。 10.0.7 到 10.0.11 将被保留。

如果您有 20 个版本总数，并且您没有提供一个包数量，如下所示： 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] 如果您想使用内联，则私钥数据。 ivSessionKey命令将打印您的

y 并生成一个加密的 zip 文件，用于与上传命令或解密命令一起使用。

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

此命令用于在使用外部源存储您的code或测试目的时。校验和是bundle的sha256（由—key-v2生成），用于验证文件的完整性后解密。它将使用私钥加密并与bundle一起发送。在加密v2中，校验和升级为bundle的“签名”。

可选，您可以提供：

--key [/path/to/my/private_key] 您的私钥路径。 --key-data [privateKey] 如果您想使用内联，则使用私钥数据。 --json 以 JSON 格式输出信息。命令将打印您的 ivSessionKeyy并生成一个加密的 zip，用于与上传命令或解密命令一起使用。

解密

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

可选，您可以提供：

--key [/path/to/my/private_key] 您的私钥路径。

--key-data [privateKey] 如果您想使用内联，则使用私钥数据。该命令主要用于测试目的，会解密 zip 并在控制台打印 base64 解密的会话密钥。

Decrypt V2

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

Optionally, you can give:

--key [/path/to/my/private_key] the path of your private key. --key-data [privateKey] the private key data, if you want to use inline. This command is mainly used for test purpose, it will decrypt the zip and print the base64 decrypted session key in the console. --checksum [checksum] the checksum of the file, it will verify the checksum after decryption.

Zip

npx @capgo/cli bundle zip [appId]

[appId] is your app ID, the format is explained here.

Optionally, you can give:

--path [/path/to/my/bundle] to upload a specific folder.
--bundle [1.0.0] 为文件名设置捆绑包版本号。
--name [myapp] 覆盖文件名。
--json 以 JSON 格式输出信息。
--no-code-check 忽略 code 检查并发送捆绑包。
--key-v2 使用新加密系统。由于新加密系统使用更好的校验和来验证文件完整性，因此这是必需的。

兼容性

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

[appId] 您的应用 ID，格式解释在这里您的新渠道名称。. [channelId] 可选项：

__CAPGO_KEEP_0__ 键以链接到您的帐户

--apikey [key] API key to link to your account.
--text 使用文本代替表格中的表情符号
--channel [channel] 检查兼容性的频道
--package-json <packageJson> package.json 的路径。对于多包仓库很有用
--node-modules <nodeModules> node_modules 的路径列表。对于多包仓库很有用（以逗号分隔，例如：../../node_modules,./node_modules）

频道

添加

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

[channelId] 您的新频道的名称 [appId] 应用 ID 的格式 com.test.app 这里有说明这里有说明.

删除

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

[channelId] 您要删除的频道名称. [appId] 应用ID的格式 com.test.app 如图所示在这里.

列表

npx @capgo/cli channel list [appId]

[appId] 应用ID的格式 com.test.app 如图所示在这里.

您可以选择填写：

--apikey [key] API key 链接到您的帐户。

设置

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

[appId] 是您的应用 ID，格式解释在这里.

可选：

--bundle [1.2.3] 您的应用程序包已经发送到云端，链接到一个频道.
--latest 从 package.json:version获取包版本号， --bundle.
--state [ normal | default ] 不能与 normal 设置频道状态，可以 default或。一个频道需要 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 禁用此频道的自动更新策略。可能的选项是：重大、次要、元数据、无。
--apikey [key] API用于链接到您的帐户。

Disable updates strategy

There are a few ways to handle disabling updates for too old versions.
Capgo cannot update native code thus an update from a version with the old native code to a version with the updated native code should not be possible. There are a couple of ways to achieve that.

__CAPGO_KEEP_0__无法更新__CAPGO_KEEP_1__，因此从使用旧__CAPGO_KEEP_2__的__CAPGO_KEEP_0__版本更新到使用更新__CAPGO_KEEP_3__的__CAPGO_KEEP_0__版本是不可能的。有几种方法可以实现这一点。 major 首先是 0.0.0 -> 1.0.0策略。它防止了从1到 0.0.0).
的更新。 minor .0.0和 0.0.0 -> 1.1.0 .1.0 1.1.0 第二种是使用"major"策略。它防止了从"major"版本更新到"minor"版本或从"minor"版本更新到"major"版本。 1.2.0. 注意此策略不能防止更新 0.1.0 -> 1.1.0