Keel × GitHub Actions

Keel 当前没有在仓库中发布可复制的 GitHub Actions workflow templates。 不存在的 keel/templates/github-actions/ 不能作为安装来源，本页也不承诺某个 runner、构建时长或 Actions 套餐额度。

建议的 CI 边界

CI 应从当前项目的 package.json、keel.json 和 keel --help 生成真实命令，不要从 roadmap 复制命令。一个最小 pipeline 通常 包含：

1. 安装锁文件依赖；
2. typecheck / lint / unit tests；
3. keel doctor；
4. 对目标平台执行真实 build；
5. 仅在显式 release gate 后 publish 或 submit；
6. 验证产物路径、hash 和目标环境。

keel publish 当前需要 bundle 路径、--platform 和 --bundle-version。Store submit 当前使用 --app-version，不是 --version。最终参数以 keel/cli/src/index.ts 和 CLI help 为准。

Secrets

不要把凭据写入 workflow、仓库文件、构建日志或 cache。根据实际命令只注入所需 secret；常见类别包括 KAS API key、project id、商店凭据和签名材料。

当前 Credentials / Submit 实现正在调整，而且本地 ~/.keel/credentials.yml 同时被多个流程引用。建立 CI 前应核对当前 CLI 行为，并为“登录不覆盖商店凭据” 建立回归测试。

Runner 选择

• iOS 编译和签名需要能运行目标 Xcode toolchain 的 macOS runner。
• Android 构建需要项目锁定的 JDK、Android SDK、NDK 和 ABI。
• 国内应用市场或依赖下载是否需要中国区 runner，必须通过实际网络请求验证。
• 自托管 runner 的权限、凭据清理与 workspace 隔离由运营方负责。

仓库在提供经过 E2E 的模板之前，不应给出固定 runner 标签、分钟倍率或预计成本。

发布前验证

• 在临时目录安装并构建 CLI/package；
• 对目标平台产生真实可运行或可提交产物；
• npm pack --dry-run 验证发布包；
• staging 执行 Build → Update/Submit 的真实链路；
• 清理 task-owned 凭据和测试产物；
• production 只做最小 smoke。

在正式模板通过端到端验证前，本页只定义集成边界，不承诺尚未发布的托管流程。