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

本机 + OTA 通道工作流

一个常见的Capgo设置使用一个 开发 频道和一个 生产环境 频道。CI 将每个 OTA 包装上传到 dev, 然后促进到 production 当你准备好时。团队经常添加 --fail-on-incompatible 以便 CI 无法意外将实时更新推送到需要新本机code的频道中。

本页面回答以下问题: 当你 故意 需要一个与频道当前本机包不兼容的包装时，会发生什么?

如果你需要了解为什么Capgo比较本机包的背景，请参阅 本机兼容性. For a full CI branch that picks OTA vs Capgo Build automatically, see 自动 OTA 或本机.

推荐渠道布局

本指南假设 dev 和 production 终端窗口

复制到剪贴板
npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app
谁获得典型上传内部/QA构建
dev每次CI推送的JS（和意图的本机基线）每次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 上传前可选的CI门控： metadata 终端窗口 --auto-min-update-version 复制到剪贴板

有意原生升级（一旦使用过，请移除该标志）

有意原生升级（一旦使用过，请移除该标志）
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)

不能

阻止意外的原生漂移。

每次上传时都需要在此处填写此项（以下推荐策略）。如果您的频道尚未开启，请忽略此项，直到您切换。 上传前可选的CI门控： 上传一个需要新native code的包 --fail-on-incompatible。这个标志是为了阻止这种情况。 当一个插件、Capacitor版本或其他native依赖项被故意改变时:

  1. 发布匹配的 native二进制文件 (App Store / Play Store, 或者 Capgo Build).
  2. 上传匹配的JS包 不 --fail-on-incompatible.
  3. 优先 --auto-min-update-version 有 metadata channel在
  4. 策略上，确保设备仍在使用旧的二进制文件的设备不会在安装新应用之前接收到新包。 --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比较/迁移营销复制。 角色：长期营销或法律段落。 见于：页面ionic-appflow.astro。 保留Capgo产品/品牌和开发人员术语。 消息键`appflow_cta_questions`（Appflow CTA问题）。 | 来自更长Capgo UI字符串（父键`capwesome_cta_questions`）。 页面/区域：Capawesome比较页面。 角色：长期营销或法律段落。 见于：页面capwesome.astro。 保留Capgo产品/品牌和开发人员术语。 消息键`capwesome_cta_questions`（Capwesome CTA问题）。 | 来自更长Capgo UI字符串（父键`consulting_faq_subtitle`）。 页面/区域：咨询服务页面。 角色：小UI标签或导航项。 见于：页面consulting.astro，页面ionic-appflow.astro，页面solutions/ionic-enterprise-plugins.astro。 消息键`appflow_plugins_or`（Appflow插件或）

    将本机二进制文件发送

  3. 构建并提交包含新插件或本机更改的iOS/Android应用程序。 直到用户安装该二进制文件，他们就不能安全地运行依赖于本机包的捆绑包 --fail-on-incompatible)

    上传匹配的OTA基线（不含）
    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 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 如何检测包的变化以及不兼容的设备意味着什么。

自动OTA或原生

Wire bundle releaseType 将 GitHub 动作或GitLab连接到CI中，让CI选择正确的路径。

版本目标

context: Capgo解决方案营销页面。角色：部分或页面标题。见于：页面解决方案/版本目标化.astro。消息键`solutions_version_targeting_title` (解决方案版本目标化标题)。| Capgo解决方案营销页面。角色：短UI标签或导航项。见于：页面解决方案/版本目标化.astro。消息键`solutions_version_targeting` (解决方案版本目标化)。

CLI: bundle

__CAPGO_KEEP_0__: 组合

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

Native + OTA Channel Workflow

如果您正在使用 Native + OTA Channel Workflow 与 Native Compatibility 用于包比较规则 Auto OTA 或 Native 用于 CI 分支 版本目标 页面/区域：Capgo 解决方案营销页面。角色：部分或页面标题。见于：页面解决方案/版本目标.astro。消息键 `solutions_version_targeting_title` (解决方案版本目标标题)。| 页面/区域：Capgo 解决方案营销页面。角色：短 UI 标签或导航项。见于：页面解决方案/版本目标.astro。消息键 `solutions_version_targeting` (解决方案版本目标)。 Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 包引用