跳过内容

GitHub 动作

直接从您的 GitHub 仓库中自动化 iOS 和 Android 的构建。使用一个工作流文件和少量仓库密钥,任何推送、标签或手动触发都可以生成签名的、可存储的应用程序——无需团队成员安装 Mac、Xcode 或 Android Studio。

无人值守发布

在 Git 中标记一个发布,然后您的签名的 iOS 和 Android 二进制文件将自动提交到 TestFlight 和 Play Store。

无本地设置

Windows 或 Linux 的贡献者可以触发 iOS 构建。无需 Xcode、无需配置问题、无需在笔记本电脑上共享签名证书。

范围内的密钥

密钥存储在 GitHub 仓库密钥中,仅对工作流运行器可见,范围仅限于您的仓库。易于旋转,易于审计。

并行构建

使用矩阵作业同时构建 iOS 和 Android。典型发布在 10 分钟内完成。

前置条件

前置条件

在设置工作流之前,请确保您有:

  • A Capgo account with an active subscription and a Capgo API key
  • Your app registered in Capgo (bunx @capgo/cli@latest app add 密钥的
  • __CAPGO_KEEP_0__ bunx @capgo/cli@latest build init 账户(如果没有,请 __CAPGO_KEEP_0__
  • 中注册您的应用(如果没有,请注册)bunx @capgo/cli@latest build request com.example.app --platform android --build-mode debug — CI 不是调试第一次构建的地方
  • The GitHub CLI (gh) 已安装并验证(gh auth login)

Capgo CLI 可以将您的本地凭据导出为可用的 .env 文件。与 gh secret set -f将整个CI/CD设置转化为三条命令 —— 无需手动进行base64编码、无需处理JSON、无需逐一复制粘贴密钥。

  1. 将您的Capgo API密钥添加为仓库密钥

    API密钥不属于每个应用程序的凭证存储,因此请手动添加一次:

    终端窗口
    gh secret set CAPGO_TOKEN --body "your_capgo_api_key_here"

    在__CAPGO_KEEP_0__控制台 Capgo dashboard 具有上传权限或更高权限。 将您的凭证导出到一个 文件

  2. __CAPGO_KEEP_0__控制台 .env __CAPGO_KEEP_0__

    运行交互式凭据管理器:

    终端窗口
    bunx @capgo/cli@latest build credentials manage --appId com.example.app

    在 TUI 中选择 导出到 .envCLI 将写入 .env.capgo.<appId> 以模式 0600 (仅可读者可读) — 例如, .env.capgo.com.example.app当 iOS 和 Android 都配置时,两个平台的密钥将在 # === IOS ===# === ANDROID === 下面的同一个文件中。

  3. .env 文件推送到GitHub Actions密钥

    The gh secret set -f command reads a dotenv file and creates one repository secret per KEY=value line:

    终端窗口
    gh secret set -f .env.capgo.com.example.app

    That’s it — every secret your workflow needs is now in GitHub. Verify with gh secret list.

  4. 创建工作流文件

    添加 .github/workflows/capgo-build.yml 到您的仓库。 选择以下三种触发模式中的一个,根据您希望如何触发构建来决定。

什么会出现在您的密钥中

标题:什么会出现在您的密钥中

参考 gh secret set -f 将创建以下仓库密钥(您的工作流 YAML 文件通过以下确切名称引用它们):

平台创建的密钥
iOSBUILD_CERTIFICATE_BASE64, P12_PASSWORD, CAPGO_IOS_PROVISIONING_MAP_BASE64, APPLE_KEY_ID, APPLE_ISSUER_ID, APPLE_KEY_CONTENT, APP_STORE_CONNECT_TEAM_ID
AndroidANDROID_KEYSTORE_FILE, KEYSTORE_KEY_ALIAS, KEYSTORE_KEY_PASSWORD, KEYSTORE_STORE_PASSWORD, PLAY_CONFIG_JSON
(手动添加)CAPGO_TOKEN

You don’t need to memorise these — the workflow examples below already reference all of them.

以下三个示例覆盖了最常见的模式。它们都使用相同的形状:clone 仓库,安装依赖项,构建 Web 资产,同步到原生,然后调用 Capgo Build with credentials passed as environment variables.

允许任何具有写入权限的人从 Actions GitHub

.github/workflows/capgo-build-manual.yml
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 (手动) → 运行工作流 触发它。

在推送一个版本标签(如 1.0.0)时,会并行构建和发布两个平台。这是最常见的生产环境设置 — v1.4.0会成为您的发布命令。 git tag v1.4.0 && git push --tags .__CAPGO_KEEP_0__/workflows/__CAPGO_KEEP_1__-build-release.yml

.github/workflows/capgo-build-release.yml
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 Actions → __CAPGO_KEEP_0__ Build (手动) → 运行工作流

3. 在主分支推送时构建调试

标题为“3. 在主分支推送时构建调试”

通过在每次推送到 main生成一个调试Android构建,早期捕捉本机构建回归。

.github/workflows/capgo-build-main.yml
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-upload

The paths 过滤器确保工作流程不会在仅有文档更改的情况下运行。 --no-playstore-upload 跳过Play Store提交(不需要),并 PLAY_CONFIG_JSON 生成一个下载URL以便于在测试设备上安装结果的APK。 --output-upload 常见模式

标题:跳过Play Store / TestFlight上传

对于测试构建,跳过商店提交:Android使用

;对于iOS,使用 --no-playstore-upload(这永远不会提交到App Store)。将其与 --ios-distribution ad_hoc __CAPGO_KEEP_0__ --output-upload 获取时间限制的二进制下载 URL。

读取构建输出 URL 和 QR code。

标题:读取构建输出 URL 和 QR code。

持久化 --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-bump

bun install 虽然JS依赖缓存已经足够快,很少情况下会有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没有访问权限(检查环境/branch保护)
iOS / Android凭证缺失错误gh secret set -f 在__CAPGO_KEEP_0__中未运行,或者在__CAPGO_KEEP_0__中运行的是一个不同的仓库。请使用 gh secret list
cap sync 在CI中失败,但在本地成功本地插件未在__CAPGO_KEEP_0__中注册,或者你忘记了 package.json__CAPGO_KEEP_0__未安装,或者__CAPGO_KEEP_0__的版本不兼容 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 managegh secret set -f .env.capgo.<appId>
平台之间的共享配置键不同 — 管理器警告并要求确认。要覆盖其中一个,请确认;要重新导出每个平台,请重新导出重新导出并重新推送 --platform ios / --platform android
build last-output 打印一个空的URL构建未通过 --output-upload或在生成工件之前失败。 outputUrl 将会 null 在记录中。 分支在 [ -n "$URL" ] 在使用它之前
build last-outputUnsupported record schemaVersion运行器位于一个比写入记录的那一个更旧的CLI上。 将生产者和读者都锁定在相同的明确版本(例如 bunx @capgo/cli@7.104.0 … 在两边)而不是 @latest,它会漂浮并在任务之间漂移

对于平台特定的构建失败,请参见 故障排除指南.