无人值守发布
在 Git 中标记一个发布,然后您的签名的 iOS 和 Android 二进制文件将自动提交到 TestFlight 和 Play Store。
复制一个包含安装步骤和本插件的完整 Markdown 指南的配置提示。
直接从您的 GitHub 仓库中自动化 iOS 和 Android 的构建。使用一个工作流文件和少量仓库密钥,任何推送、标签或手动触发都可以生成签名的、可存储的应用程序——不需要团队成员安装 Mac、Xcode 或 Android Studio。
无人值守发布
在 Git 中标记一个发布,然后您的签名的 iOS 和 Android 二进制文件将自动提交到 TestFlight 和 Play Store。
无本地设置
Windows 或 Linux 的贡献者可以触发 iOS 构建。无需 Xcode、无需配置、无需在笔记本电脑上共享签名证书。
范围内的密钥
密钥存储在 GitHub 仓库密钥中,仅对工作流运行器可见,范围仅限于您的仓库。易于旋转,易于审计。
并行构建
使用矩阵作业同时构建 iOS 和 Android。典型发布时间在 10 分钟内
在设置工作流之前,请确保您有:
bunx @capgo/cli@latest app add 您的应用程序已在bunx @capgo/cli@latest build init 本地配置了构建凭据( 请参见 Managing Credentialsbunx @capgo/cli@latest build request com.example.app --platform android --build-mode debug — CI 不是调试第一次构建的地方gh) 已安装并已验证(gh auth login)The Capgo CLI 可以将您的本地凭据导出为可用的 .env 文件。结合 gh secret set -f, 这样就可以将整个 CI/CD 设置简化为三个命令 —— 不需要手动进行 base64 编码、JSON 处理或复制粘贴密钥。
将您的 Capgo API 密钥添加为仓库密钥
由于 API 密钥不属于每个应用程序的凭证存储,因此请手动添加一次:
gh secret set CAPGO_TOKEN --body "your_capgo_api_key_here"在 __CAPGO_KEEP_0__ 控制台中 Capgo dashboard 需要具有上传权限或更高的权限。 将您的凭证导出到一个 文件
with .env upload
运行交互式凭据管理器:
bunx @capgo/cli@latest build credentials manage --appId com.example.app在 TUI 中选择 导出到 .env。CLI 以写入模式 .env.capgo.<appId> 到当前目录中 — 例如, 0600 当 iOS 和 Android 都配置时,两者的密钥都将写入 .env.capgo.com.example.app和 # === IOS === 节标题。 iOS 和 Android 的环境变量名称是不同的,因此合并它们是冲突的。 # === ANDROID === 需要每个平台的文件吗?
将 .env 文件推送到GitHub Actions密钥
命令读取一个dotenv文件并为每一行创建一个仓库密钥: gh secret set -f 终端窗口 KEY=value 复制到剪贴板
gh secret set -f .env.capgo.com.example.appThat’s it — every secret your workflow needs is now in GitHub. Verify with gh secret list.
创建工作流文件
添加 .github/workflows/capgo-build.yml 到您的仓库。 选择以下三种触发模式中的一个,根据您希望如何触发构建。
参考 gh secret set -f 将创建这些仓库密钥(您的工作流 YAML 文件通过以下确切名称引用它们):
| 平台 | 创建的密钥 |
|---|---|
| iOS | BUILD_CERTIFICATE_BASE64, P12_PASSWORD, CAPGO_IOS_PROVISIONING_MAP_BASE64, APPLE_KEY_ID, APPLE_ISSUER_ID, APPLE_KEY_CONTENT, APP_STORE_CONNECT_TEAM_ID |
| Android | ANDROID_KEYSTORE_FILE, KEYSTORE_KEY_ALIAS, KEYSTORE_KEY_PASSWORD, KEYSTORE_STORE_PASSWORD, PLAY_CONFIG_JSON |
| (手动添加) | CAPGO_TOKEN |
您不需要记住这些 — 下面的工作流程示例已经引用了所有它们。
以下三个示例涵盖了最常见的模式。它们都使用相同的形状:检查仓库,安装依赖项,构建 Web 资产,同步到本机,然后调用 Capgo 使用环境变量传递凭据的 Build。
允许任何具有写入访问权限的人从 Actions tab in GitHub with a platform dropdown. Useful for ad-hoc test builds or kicking off a release on demand.
name: Capgo Build (Manual)
on: workflow_dispatch: inputs: platform: description: 'Platform to build' required: true default: 'android' type: choice options: [ios, android, both] mode: description: 'Build mode' required: true default: 'debug' type: choice options: [debug, release]
jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: oven-sh/setup-bun@v2 with: bun-version: latest
- run: bun install --frozen-lockfile - run: bun run build - run: bunx cap sync
- name: Trigger Capgo Build env: CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }} BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }} P12_PASSWORD: ${{ secrets.P12_PASSWORD }} CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }} APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }} APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }} APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }} APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }} ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }} KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }} KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }} KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }} PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }} run: | bunx @capgo/cli@latest build request com.example.app \ --platform ${{ inputs.platform }} \ --build-mode ${{ inputs.mode }}替换 com.example.app 使用您的应用 ID。 一旦提交,前往 Actions → Capgo Build (手动) → 运行工作流 来触发它。
在推送一个版本标签(如 v1.4.0)时,会并行构建和发布两个平台。这是最常见的生产环境设置 — git tag v1.4.0 && git push --tags 会成为您的发布命令。
name: Capgo Build (Release)
on: push: tags: - 'v*'
jobs: build: runs-on: ubuntu-latest strategy: fail-fast: false matrix: platform: [ios, android] steps: - uses: actions/checkout@v4 - uses: oven-sh/setup-bun@v2 with: bun-version: latest
- run: bun install --frozen-lockfile - run: bun run build - run: bunx cap sync ${{ matrix.platform }}
- name: Build ${{ matrix.platform }} env: CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }} # iOS BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }} P12_PASSWORD: ${{ secrets.P12_PASSWORD }} CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }} APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }} APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }} APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }} APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }} # Android ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }} KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }} KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }} KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }} PLAY_CONFIG_JSON: ${{ secrets.PLAY_CONFIG_JSON }} run: | bunx @capgo/cli@latest build request com.example.app \ --platform ${{ matrix.platform }} \ --build-mode release矩阵在独立的运行器上并行运行 iOS 和 Android。设置 fail-fast: false 意味着 iOS 构建失败不会取消正在进行的 Android 构建(反之亦然)—当一个平台出现暂时性签名问题时,这很有用。
通过在每次推送到时生成一个调试Android构建来尽早捕获本机构建回归。 main费用低廉,反馈快,可以跳过Play Store上传以使其成为纯粹的烟雾测试。
name: Capgo Build (Main)
on: push: branches: [main] paths: - 'src/**' - 'android/**' - 'ios/**' - 'package.json' - 'capacitor.config.*'
jobs: smoke-build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: oven-sh/setup-bun@v2 with: bun-version: latest
- run: bun install --frozen-lockfile - run: bun run build - run: bunx cap sync android
- name: Smoke build (Android debug) env: CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }} ANDROID_KEYSTORE_FILE: ${{ secrets.ANDROID_KEYSTORE_FILE }} KEYSTORE_KEY_ALIAS: ${{ secrets.KEYSTORE_KEY_ALIAS }} KEYSTORE_KEY_PASSWORD: ${{ secrets.KEYSTORE_KEY_PASSWORD }} KEYSTORE_STORE_PASSWORD: ${{ secrets.KEYSTORE_STORE_PASSWORD }} run: | bunx @capgo/cli@latest build request com.example.app \ --platform android \ --build-mode debug \ --no-playstore-upload \ --output-uploadThe paths 过滤器确保工作流程不会在仅有文档更改的情况下运行。 --no-playstore-upload 跳过Play Store提交(无需)并 PLAY_CONFIG_JSON 生成用于测试设备安装的APK下载链接。 --output-upload 常见模式
;对于iOS,使用 --no-playstore-upload(这永远不会提交到App Store)。将其与 --ios-distribution ad_hoc 任何其他选项结合 --output-upload 获取时间限制的二进制下载 URL。
Pass --output-record <path> 在构建成功时将构建物件 URL 和 QR code 持久化到磁盘,然后在随后的步骤中读取。 build last-output无日志爬取,无正则表达式。
- name: Build env: CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }} # ...credentials... run: | bunx @capgo/cli@latest build request com.example.app \ --platform android --build-mode debug \ --output-upload --output-retention 1d \ --output-record /tmp/build.json
- name: Comment on PR with build URL env: GH_TOKEN: ${{ github.token }} run: | URL=$(bunx @capgo/cli@latest build last-output --path /tmp/build.json --field outputUrl) if [ -n "$URL" ]; then gh pr comment ${{ github.event.pull_request.number }} \ --body "Debug build ready: $URL" fi--output-record /tmp/build.json 写入一个 JSON 记录(带有 jobId, status, outputUrl, qrCodeAscii, qrCodePngPath, finishedAt)和一个 PNG QR code。 /tmp/build.json.qr.png. build last-output 读取它:
--field outputUrl 打印仅下载 URL(换行终止;安全用于 URL=$(...)).--field qrCodePngPath 打印 PNG 路径以便您可以将其作为 PR 附件上传。--qr 打印渲染的 ASCII QR — 将其放入 Markdown code 围栏中,用于 PR评论的内联扫描。默认情况下,每个发布构建都会增加构建号。要将其固定到您控制的值(例如 Git 标签),请传递 --skip-build-number-bump:
- name: Set version from tag run: | VERSION="${GITHUB_REF#refs/tags/v}" # Update package.json or your version source here bun pm version "$VERSION" --no-git-tag-version
- name: Build env: CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }} # ...credentials... run: | bunx @capgo/cli@latest build request com.example.app \ --platform ios --build-mode release \ --skip-build-number-bumpbun install 已经足够快了,JS依赖缓存很少能带来收益,但Capacitor的本地依赖(CocoaPods,Gradle)在大型项目中值得缓存:
- uses: actions/cache@v4 with: path: | ~/.bun/install/cache ios/App/Pods android/.gradle key: ${{ runner.os }}-capgo-${{ hashFiles('**/bun.lock', '**/Podfile.lock') }}| 症状 | 可能原因 |
|---|---|
CAPGO_TOKEN is not set | 密钥未添加,或者任务没有访问权限(检查环境/branch保护) |
| 缺少iOS/Android凭证错误 | gh secret set -f 未运行,或者在不同的仓库中运行。请与 gh secret list |
cap sync 在CI中失败,但在本地成功 | 本地插件没有 package.json,或者你忘记了 bun install 之前 cap sync |
| 构建成功,但在 App Store Connect 中没有应用出现 | 团队 ID 错误,或应用记录尚未在 App Store Connect 中存在。请在本地验证 bunx @capgo/cli@latest build credentials manage |
| 上传项目后构建卡住 | 项目存档过大 — 检查是否正在上传(它不应该默认上传) node_modules 配置文件指向的 bundle ID 与 Xcode 签名的不同。重新运行 |
Provisioning profile doesn't match bundle ID | 以刷新配置文件,然后重新导出 build init 本地更改了凭据,但 CI 还是失败 build credentials manage |
| 不要忘记重新导出并重新推送: | 管理器拒绝写入组合文件 bunx @capgo/cli@latest build credentials manage → gh secret set -f .env.capgo.<appId> |
| 共享配置键在各个平台之间存在差异 — 管理器警告并要求确认。要覆盖其中一个,或者重新导出每个平台 | 重新导出并重新推送 --platform ios / --platform android |
build last-output 打印一个空的 URL | 构建未通过 --output-upload或者在生成产物之前就失败了。 outputUrl 将会 null 在记录中。 [ -n "$URL" ] 在 |
build last-output 在使用它之前 Unsupported record schemaVersion | The runner is on an older CLI than the one that wrote the record. Pin both producer and reader to the same explicit version (e.g. bunx @capgo/cli@7.104.0 … 构建器位于一个较旧的__CAPGO_KEEP_0__版本上,而记录是由一个更新的版本写入的。请将生产者和读者都固定在相同的显式版本(例如 @latest在两边)而不是 |
,它会浮动并在任务之间漂移 对于平台特定的构建失败,请参见.