Saltare al contenuto

Esegui costruzioni native dal pannello CI

A volte hai bisogno di un binario iOS o Android firmato senza unire un PR o tag di rilascio — un build di QA, una riassegnazione di store o un TestFlight unico. Ogni host maggiore code può avviare una pipeline dalla sua interfaccia web. Questa guida mostra come collegare quella UI a Capgo Build.

Nessuna Cerimonia Git

Clicca su Esegui workflow / Esegui pipeline. Capgo Build compila dalla branch che scegli.

Impostazioni Sicure

Piattaforma e modalità di build utilizzano scelte con vincoli dove il host le supporta (GitHub / Bitbucket / Azure). Le variabili GitLab rimangono modificabili per esecuzione a meno che non definisci Impostazioni della pipeline con options.

Segreti identici a CI

Ripeti le credenziali di Capgo già presenti nel tuo repository. Niente di nuovo sui laptop.

GitHub's azioni tab può avviare qualsiasi flusso di lavoro che dichiari workflow_dispatch.

github/flussi di lavoro/capgo-costruzione-manuale.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. Apre il repository GitHub nel browser
  2. Vai a azioni
  3. Scegli Capgo Costruzione (Manuale)
  4. Clicca Esegui workflow
  5. Scegli il ramo, la piattaforma e il modo
  6. Conferma Esegui workflow

Chiunque abbia write si esegue in un ambiente __CAPGO_KEEP_0__ chiamato release Esegue una run a un ambiente GitHub chiamato production in carica, le regole di protezione dell'ambiente non si applicano mai. environment: Durante l'esecuzione, le regole di protezione dell'ambiente non si applicano.

GitLab può eseguire un lavoro da Costruisci → Pipeline → Esegui pipeline quando il lavoro è disponibile per quel ramo.

# 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. Apri il progetto GitLab
  2. Vai a Costruisci → Pipeline → Esegui pipeline
  3. Scegli il ramo
  4. Seleziona optionalmente PLATFORM / BUILD_MODE le variabili per questa esecuzione
  5. Inizia la pipeline, quindi clicca sul pulsante di riproduzione su capgo_manuale nativo

when: manual mantiene il lavoro da eseguire su ogni push; l'interfaccia web (o un token di trigger della pipeline) lo avvia su richiesta.

Use a custom pipeline so the Bitbucket UI can pass variables:

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"

Eseguilo da Pipelines → Esegui pipeline → Personalizzato: capgo-costruzione nativaMemorizza CAPGO_TOKEN e materiale di firma sotto Impostazioni repository → Pipelines → Variabili repository.

azure-pipelines-capgo-manuale.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 e pr: none mantieni il flusso di lavoro fuori dai run automatici CI/PR affinché inizi da Pipelines → Esegui pipeline Se il progetto utilizza le politiche di rilascio di Azure Repos che attivano questa pipeline, disabilita quella politica separatamente. Aggiungi CAPGO_TOKEN e i valori di firma a un gruppo di variabili contrassegnato come segreto.

InputValori suggeritiNote
Piattaformaios, android, bothMatrice quando both
Modalitàdebug, releaseDebug + --output-upload per collegamenti QA
distribuzione iOSapp_store, ad_hocL'ad-hoc non invia mai all'App Store

Per artefatti QA scaricabili, combinare debug Android con --no-playstore-upload --output-upload e leggere l'URL con build last-output.

  • Preferire le regole di protezione dell'ambiente (GitHub) o le variabili protette (GitLab) per release i costrutti che inviano a negozi.
  • Non inserire le password di firma nelle workflow inputs – solo nelle segrete/variabili.
  • Limitare chi può eseguire le workflow con ruoli di repository e permessi di team (è richiesta la scrittura su GitHub). La protezione di branch da sola non controlla Eseguire workflow; add an in-workflow authorization check if only a narrower group may start builds.