跳过内容

从 CI UI 触发原生构建

有时您需要签名的 iOS 或 Android 二进制文件,而不需要合并 PR 或切换发布标签——QA 构建、商店重新提交或一次性 TestFlight。每个主要 code 主机都可以从其 Web UI 开始管道。这份指南展示了如何将 UI 与 Capgo Build 链接起来。

您将获得什么

标题:您将获得什么

无 Git 仪式

点击运行工作流 / 运行管道。Capgo Build 从您选择的 branch 编译。

安全输入

平台和构建模式使用受限的选择,其中主机支持它们(GitHub / Bitbucket / Azure)。GitLab 变量除非您定义了pipeline inputs,否则仍可编辑 输入管道options.

相同的机密

重用Capgo Build凭据已在您的仓库中。无需在笔记本电脑上添加任何新内容

  • Capgo Build在本地或CI中工作—参见 入门
  • 已在主机上签名的机密(对于GitHub, 使用CLI和 gh secret set -f)
  • CAPGO_TOKEN 以掩码密钥/CI变量形式存储

GitHub的 动作 工作流程标签页可以启动任何声明了 workflow_dispatch.

1. 添加工作流程

标题:1. 添加工作流程
github/workflows/capgo-build-manual.yml
name: Capgo Build (Manual)
on:
workflow_dispatch:
inputs:
platform:
description: Platform to build
required: true
default: both
type: choice
options: [ios, android, both]
mode:
description: Build mode
required: true
default: debug
type: choice
options: [debug, release]
ref_note:
description: Optional note for the run summary
required: false
type: string
jobs:
build:
runs-on: ubuntu-latest
environment: ${{ inputs.mode == 'release' && 'production' || 'build-debug' }}
strategy:
fail-fast: false
matrix:
platform: ${{ fromJSON(inputs.platform == 'both' && '["ios","android"]' || format('["{0}"]', inputs.platform)) }}
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v6
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
- run: npx cap sync ${{ matrix.platform }}
- name: Capgo Build
env:
CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
CAPGO_IOS_PROVISIONING_MAP: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP }}
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: |
EXTRA=""
if [ "${{ inputs.mode }}" = "debug" ] && [ "${{ matrix.platform }}" = "android" ]; then
EXTRA="--no-playstore-upload --output-upload"
fi
npx @capgo/cli@latest build request com.example.app \
--platform ${{ matrix.platform }} \
--build-mode ${{ inputs.mode }} \
$EXTRA
  1. 打开GitHub仓库
  2. 前往 动作
  3. 选择 Capgo手动构建
  4. 点击 运行工作流
  5. 选择分支、平台和模式
  6. 确认 运行工作流

任何具有 可以开始构建。样本映射 release 运行到一个GitHub环境 production —创建该环境并添加所需的审阅者,以便存储构建等待批准。没有 environment: 在工作中,环境保护规则永远不会应用。

GitLab 可以在该 branch 可用时运行一个作业 构建 → Pipelines → 运行 pipeline 当作业可用时,会运行该 branch 的作业。

# Job fragment for .gitlab-ci.yml
stages:
- build
variables:
APP_ID: com.example.app
PLATFORM: android # override from Run pipeline UI
BUILD_MODE: debug
capgo_native_manual:
stage: build
when: manual
script:
- npm ci
- npm run build
- npx cap sync "$PLATFORM"
- |
npx @capgo/cli@latest build request "$APP_ID" \
--platform "$PLATFORM" \
--build-mode "$BUILD_MODE"
rules:
# Actions / Pipelines UI → manual play button
- if: '$CI_PIPELINE_SOURCE == "web"'
when: manual
# Pipeline trigger token / webhook → run automatically
- if: '$CI_PIPELINE_SOURCE == "trigger"'
when: on_success
- when: never
  1. 打开 GitLab 项目
  2. 前往 构建 → Pipelines → 运行 pipeline
  3. 选择 branch
  4. 可选地设置 PLATFORM / BUILD_MODE 此次运行的变量
  5. 启动管道,然后点击 capgo_native_manual

when: manual 在每次推送时不让任务立即运行;通过 (或一个) pipeline触发令牌) 可以按需启动它。

Bitbucket Pipelines

标题:Bitbucket Pipelines

使用自定义管道,让 Bitbucket UI 可以传递变量:

bitbucket-pipelines.yml
pipelines:
custom:
capgo-native-build:
- variables:
- name: PLATFORM
default: android
allowed-values:
- ios
- android
- name: BUILD_MODE
default: debug
allowed-values:
- debug
- release
- step:
name: Capgo Build
image: node:24
script:
- npm ci
- npm run build
- npx cap sync "$PLATFORM"
- npx @capgo/cli@latest build request com.example.app --platform "$PLATFORM" --build-mode "$BUILD_MODE"

管道 → 运行管道 → 自定义:capgo-native-build存储 CAPGO_TOKEN 和签名材料 仓库设置 → Pipelines → 仓库变量.

Azure DevOps

Azure DevOps
azure-pipelines-capgo-manual.yml
trigger: none # disable CI push triggers
pr: none # also disable PR triggers (GitHub/Bitbucket-backed projects)
parameters:
- name: platform
displayName: Platform
type: string
default: android
values:
- ios
- android
- name: buildMode
displayName: Build mode
type: string
default: debug
values:
- debug
- release
pool:
vmImage: ubuntu-latest
steps:
- task: NodeTool@0
inputs:
versionSpec: '24.x'
- script: |
npm ci
npm run build
npx cap sync ${{ parameters.platform }}
npx @capgo/cli@latest build request com.example.app \
--platform ${{ parameters.platform }} \
--build-mode ${{ parameters.buildMode }}
env:
CAPGO_TOKEN: $(CAPGO_TOKEN)
# map other signing secrets from Library → Variable groups

trigger: none 并且 pr: none 保持管道不自动触发 CI/PR 运行, 管道 → 运行管道 (或一个 webhook). 如果项目使用 Azure Repos 分支策略排队这个管道,请单独禁用该策略。 添加 CAPGO_TOKEN 并将签名值添加到标记为秘密的变量组。

推荐输入
输入建议值注意
平台ios, android, both矩阵时 both
模式debug, release调试 + --output-upload 用于 QA 链接
iOS 分发app_store, ad_hocAd-hoc never 提交到 App Store

对于可下载的 QA artifact,结合调试 Android 与 --no-playstore-upload --output-upload 并阅读 URL build last-output.

安全注意事项

标题:安全注意事项
  • 优先使用环境保护规则(GitHub)或受保护的变量(GitLab) release 提交到商店的构建
  • 不要将签名密码放在工作流中 inputs — 只在secrets/variables中。
  • 限制谁可以运行工作流,使用仓库角色和团队权限(写入访问权限需要在GitHub上)。仅靠 branch 保护无法控制 运行工作流; 如果只有一个更窄的组可以启动构建,请在工作流中添加授权检查。