跳过内容

继续

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

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

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

推荐渠道布局

本指南假设 devproduction 创建渠道

终端窗口
npx @capgo/cli@latest channel add production com.example.app
npx @capgo/cli@latest channel add dev com.example.app
渠道谁获得典型上传
dev内部/测试版本每次CI推送的JS(和意图的本机基线)
production用户存储仅在发布就绪时上传或推广

--fail-on-incompatible 在两个频道上都是一个不错的默认值 每日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 直到您切换为止。 --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)

标题:有意本机升级(一旦完成,请移除标志)

不能 不能 上传一个需要新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 使用带有channel的策略 metadata 以便设备仍在使用旧的二进制文件的设备不会在安装新应用之前接收到新的包。
  4. 在baseline上传之后, --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问题)。

    在Appflow比较/迁移营销复制页面。 角色:长期营销或法律段落。 见于:页面ionic-appflow.astro。 保留Capgo产品/品牌和开发者术语。 消息键:appflow_cta_questions (Appflow CTA问题)。

  3. 在Capawesome比较页面。 角色:长期营销或法律段落。 见于:页面capwesome.astro。 保留Capgo产品/品牌和开发者术语。 消息键:capwesome_cta_questions (Capwesome CTA问题)。 --fail-on-incompatible)

    在咨询服务页面。 角色:小型UI标签或导航项。 见于:页面consulting.astro, 页面ionic-enterprise-plugins.astro, 页面解决方案/ionic-enterprise-plugins.astro。 消息键:appflow_plugins_or (Appflow插件或)。
    npx @capgo/cli@latest bundle upload com.example.app \
    --channel production \
    --auto-min-update-version

    此记录在渠道上的新本机包。后续检查使用该基线。 bundle releaseType / --fail-on-incompatible 恢复受保护的OTA上传

  4. 后续仅使用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
相关

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

Section titled “Native + OTA Channel Workflow”

如果您正在使用 Native + OTA Channel Workflow 将其与 Native Compatibility 用于包比较规则 Auto OTA 或 Native 用于 CI 分支 版本目标 context Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 包引用