跳过内容
Capgo - __CAPGO_KEEP_2__ Live Updates for Capacitor Apps Capgo

复制页面选项

一个常见的Capgo设置使用一个 开发 频道和一个 生产 channel。CI将每个OTA包上传到 dev当你准备好时,它就会升级 production 团队经常添加 --fail-on-incompatible 所以 CI 不会意外地将需要新本机 code 的 live update 发布

本页面回答以下问题: 当你 故意 需要一个与当前的本机包不兼容的捆绑包时

如果你需要了解为什么 Capgo 比较本机包的背景，请参见 本机兼容性。要查看自动选择 OTA 还是 Capgo Build 的完整 CI Branch，请参见 Auto OTA 或本机.

推荐渠道布局

本指南假设 dev 和 production channels已经存在。需要时首先创建它们：

终端窗口
npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app
渠道谁获得它典型上传
dev内部/ QA 版本每次 CI 推送的 JS (和意图的本机基准)
production应用商店用户只有发布就绪时才推送或上传

--fail-on-incompatible 是双通道的合理默认值 每日OTA上传。它将您上传的捆绑包中的本机包与该通道上当前的捆绑包进行比较 如果它们不同，上传将退出非零状态，什么也不会发布。每日OTA（保留标志）

标题：每日OTA（保留标志）

当更改仅为JavaScript且本机包与通道匹配时：

终端窗口

复制到剪贴板
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)

标题：意图的原生升级（一旦丢弃标志)

您

context cannot 不能上传需要新原生code的捆绑包，同时保留 --fail-on-incompatible。该标志存在于阻止这种情况的目的。当一个插件、Capacitor版本或其他本机依赖项在故意改变时：

  1. 将匹配的 本机二进制文件 (App Store / Play Store, 或 Capgo 构建).
  2. 上载匹配的JS包 不 --fail-on-incompatible.
  3. 优先 --auto-min-update-version 与渠道在 metadata 策略上，设备仍在旧二进制文件上，不会在安装新应用之前接收新包。
  4. 在此基线上传后，恢复正常的OTA CI（并保持 --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.

  2. 在Capacitor Live Update替代方案比较页面。 角色：长期营销或法律段落。 见：页面alternatives.astro。 保留Capgo产品/品牌和开发者术语。 消息键`alternatives_cta_questions`（替代方案CTA问题）。 | 来自更长Capgo UI字符串（父键`appflow_cta_questions`）。 页面/区域：Appflow比较/迁移营销复制。 角色：长期营销或法律段落。 见：页面alternatives/ionic-appflow.astro。 保留Capgo产品/品牌和开发者术语。 消息键`appflow_cta_questions`（Appflow CTA问题）。 | 来自更长Capgo UI字符串（父键`capwesome_cta_questions`）。 页面/区域：Capawesome比较页面。 角色：长期营销或法律段落。 见：页面alternatives/capawesome.astro。 保留Capgo产品/品牌和开发者术语。 消息键`capwesome_cta_questions`（Capwesome CTA问题）。 | 来自更长Capgo UI字符串（父键`consulting_faq_subtitle`）。 页面/区域：咨询服务页面。 角色：小节标题或标语。 见：页面咨询.astro。 保留Capgo产品/品牌和开发者术语。 消息键`consulting_faq_subtitle`（咨询FAQ字幕）。 | 来自Capacitor Live Update替代方案比较页面。 角色：短UI标签或导航项。 见：页面alternatives/ionic-appflow.astro，页面ionic-enterprise-plugins.astro，页面解决方案/ionic-enterprise-plugins.astro。 消息键`appflow_plugins_or`（Appflow插件或）

    将原生二进制文件发送

  3. 上传匹配的 OTA 基线（无需 Live Update） --fail-on-incompatible)

    终端窗口
    npx @capgo/cli@latest bundle upload com.example.app \
      --channel production \
      --auto-min-update-version

    本记录了该频道上的新本地包。之后 bundle releaseType / --fail-on-incompatible 会使用该基线。

  4. 恢复受保护的OTA上传

    后续仅使用JS的发布将再次使用两个标志:

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

常见问题

常见问题

我可以保持 --fail-on-incompatible 并且仍然推送一个本机不兼容的捆绑包吗

常见问题

我可以保持 --fail-on-incompatible 并且仍然推送一个本机不兼容的捆绑包吗 --auto-min-update-version 不。 如果上传的本机包与通道的实时捆绑包不同，则该标志故意失败命令。 为有意的本机升级，省略该标志（并使用

当你可以时）

一次性上传没有该标志是正确的方法吗

常见问题

是的。 这是支持的方式来在您发布新二进制文件后推进通道的本机基线。 保持该标志在每次其他OTA上传中，以便意外的本机漂移仍然会失败CI。 dev 首先，然后 production?

标题：我应该先上传到开发环境，然后是生产环境吗？

是的，如果您的流程与此匹配。运行相同的规则 每个频道:与目标频道上的最新内容进行兼容性检查。推广或重新上传到 production 只有当 dev 看起来不错时，使用原生基线上传（不 --fail-on-incompatible）在每个需要记录新原生包的频道上。

如果我上传带有标志的新原生包？

标题：如果我上传带有标志的新原生包？

CI 失败，Capgo 不会将该上传推送。这种结果是预期的。要么是意外的变化（修复原生包并尝试 OTA），要么是故意的（使用上面的原生路径）。

哪个标志应该添加到哪个任务中？

Section titled “哪个标志放哪个任务？”
路径何时上传标志
OTA仅 JS；native 包匹配频道--fail-on-incompatible + --auto-min-update-version (如果频道开启，则必填) metadata)
Native 基线新 native 二进制 + 匹配的 JS 包否 --fail-on-incompatible; 保持 --auto-min-update-version
相关

原生兼容性

原生包 Capgo 如何检测包的漂移以及不兼容的设备意味着什么。

自动OTA或原生

Wire bundle releaseType 将其 GitHub 动作或GitLab导入CI，选择正确的路径。

版本目标

context

CLI: 应用程序包

__CAPGO_KEEP_0__:打包

上传、兼容性、releaseType和相关标志的参考

继续原生+OTA通道工作流

如果您正在使用 原生 + OTA 通道工作流 为了在原生发布中保持Live Update的安全，连接它 原生兼容性 用于包比较规则。 自动OTA或原生OTA 用于 CI 分支。 版本目标 context: Page/area: Capgo solutions marketing page. Role: Section or page heading. Seen in: page solutions/version-targeting.astro. Message key `solutions_version_targeting_title` (Solutions Version Targeting Title). | Page/area: Capgo solutions marketing page. Role: Short UI label or navigation item. Seen in: site header, component SolutionsMegaMenu.astro, page solutions/version-targeting.astro. Message key `solutions_version_targeting` (Solutions Version Targeting). Capgo CLI 本地包引用 __CAPGO_KEEP_0__ __CAPGO_KEEP_1__