Native + 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

渠道	谁会收到	典型上传
dev	内部/QA版本	每次CI推送的JS（和意图的本机基线）
production	用户存储	仅在发布就绪时才上传或推广

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

标题：每日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 可选的CI门控上传: --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)

您

您 不能 上传一个需要新本机code的捆绑包 --fail-on-incompatible。这个标志是为了阻止这种情况。 当一个插件、Capacitor版本或其他本机依赖项在目的地更改时:

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

   将本机二进制文件发送

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

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

   该通道记录了新native包。后续的检查将使用该基线。 bundle releaseType / --fail-on-incompatible 恢复受保护的OTA上传

4. 后续的JS-only发布将使用以下标志:

   终端窗口

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

将native基线上传视为一个

专门的CI任务 (或手动发布步骤),而不是将其添加到默认OTA任务中。默认任务应该始终保持 protectedTokens --fail-on-incompatible，并且在 metadata 在渠道中也应保留 --auto-min-update-version.

常见问题

标题：可以保留 --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 为了在原生发布中保持实时更新的安全性,将其与 原生兼容性 用于包比较规则 自动OTA或原生 用于CI分支 版本目标 用于元数据楼层,以及 Capgo CLI 用于上传标志