原生兼容性
原生包的Capgo如何检测包的漂移以及不兼容的设备意味着什么。
复制安装提示和本插件的完整 Markdown 指南。
一个常见的Capgo设置使用一个 开发 频道和一个 生产环境 频道。CI 将每个 OTA 包装上传到 dev, 然后促进到 production 当你准备好时。团队经常添加 --fail-on-incompatible 以便 CI 无法意外将实时更新推送到需要新本机code的频道中。
本页面回答以下问题: 当你 故意 需要一个与当前频道的本机包不兼容的包装时,
如果你需要了解为什么Capgo比较本机包,请参阅 本机兼容性。要查看自动选择 OTA 或Capgo Build 的完整 CI Branch,请参阅 自动 OTA 或本机.
本指南假设 dev 和 production 创建渠道
npx @capgo/cli@latest channel add production com.example.appnpx @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依赖项被故意改变时:
--fail-on-incompatible.--auto-min-update-version 使用带有channel的策略 metadata 以便设备仍在使用旧的二进制文件的设备不会在安装新应用之前接收到新的包。--fail-on-incompatible 恢复到正常的OTA CI (并保持) --auto-min-update-version 直到渠道保持在 metadata).一次性:启用元数据门控
npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata重复对 dev 如果该渠道也接收到有意的本机基线。 在切换后,每次上传到该渠道都必须包含 --auto-min-update-version 或 --min-update-version.
在Capacitor live-update替代方案比较页面。 角色:长期营销或法律段落。 见于:页面alternatives.astro。 保留Capgo产品/品牌和开发者术语。 消息键:alternatives_cta_questions (替代方案CTA问题)。
在Appflow比较/迁移营销复制页面。 角色:长期营销或法律段落。 见于:页面ionic-appflow.astro。 保留Capgo产品/品牌和开发者术语。 消息键:appflow_cta_questions (Appflow CTA问题)。
在Capawesome比较页面。 角色:长期营销或法律段落。 见于:页面capwesome.astro。 保留Capgo产品/品牌和开发者术语。 消息键:capwesome_cta_questions (Capwesome CTA问题)。 --fail-on-incompatible)
npx @capgo/cli@latest bundle upload com.example.app \ --channel production \ --auto-min-update-version此记录在渠道上的新本机包。后续检查使用该基线。 bundle releaseType / --fail-on-incompatible 恢复受保护的OTA上传
后续仅使用JS的发布使用以下标志:
终端窗口
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 当可以时)。
是的。这是支持的方式来在您发布新二进制文件后推进渠道的本机基线。保留标志在每次其他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
CLI: bundle
__CAPGO_KEEP_0__:捆绑
如果您正在使用 Native + OTA Channel Workflow 将其与 Native Compatibility 用于包比较规则 Auto OTA 或 Native 用于 CI 分支 版本目标 context Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 包引用