Avvia costruzioni native dalla UI di CI

Copia un prompt di configurazione con i passaggi di installazione e la guida markdown completa per questo plugin.

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

Cosa Otterrai

Nessuna Cerimonia Git

Esegui workflow / Esegui pipeline. Capgo Costruzione compila dalla branca che scegli.

Input sicuri

Utilizza scelte con vincoli per piattaforma e modalità di costruzione, se il host lo supporta (GitHub / Bitbucket / Azure). Le variabili GitLab rimangono editabili per esecuzione a meno che non definisci input della pipeline con options.

Lo stesso segreto per la CI

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

Prerequisiti

Capgo Costruzione funziona una volta localmente o in CI — vedi Avvio rapido
Segreti già presenti nel host (per GitHub, esporta con il CLI e gh secret set -f)
CAPGO_TOKEN memorizzato come un segreto mascherato / variabile CI

GitHub Azioni

GitHub's Azioni la scheda Azioni può avviare qualsiasi workflow che dichiara workflow_dispatch.

1. Aggiungi il workflow

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

2. Eseguiolo dall'interfaccia utente

Apre il repository GitHub nel browser
Vai a Azioni
Scegli Capgo Build (Manuale)
Clicca Esegui workflow
Scegli il ramo, la piattaforma e il modo
Conferma Esegui workflow

Chiunque abbia scrivi l'accesso può avviare una build. Le mappe di esempio release vengono eseguite in un ambiente GitHub chiamato production — crea quell'ambiente e aggiungi i revisori richiesti affinché le build attendano l'approvazione. Senza environment: sulla postazione, le regole di protezione dell'ambiente non si applicano mai.

GitLab CI

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

Apre il progetto GitLab
Vai a Costruisci → Pipeline → Esegui pipeline
Scegli il ramo
Aggiungi eventualmente PLATFORM / BUILD_MODE variabili per questa esecuzione
Esegui la pipeline, quindi clicca sul pulsante di riproduzione capgo_manuale nativo

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

Pipelines di Bitbucket

Usa una pipeline personalizzata affinché l'interfaccia utente di Bitbucket possa passare variabili:

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"

Esegui da Pipelines → Esegui pipeline → Personalizzato: capgo-native-build . Salva CAPGO_TOKEN e materiale di firma Impostazioni repository → Pipeline → Variabili repository.

Azure DevOps

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 mantenere la pipeline fuori dai CI/PR automatici affinché parta da Pipelines → Esegui pipeline (o un webhook). Se il progetto utilizza le politiche di rami di Azure Repos che attivano questa pipeline, disabilita separatamente quella politica. Aggiungi CAPGO_TOKEN e valori di firma a un gruppo di variabili contrassegnato come segreto.

Input consigliati

Input	Valori suggeriti	Note
Piattaforma	`ios`, `android`, `both`	Matrice quando `both`
Modalità	`debug`, `release`	Debug + `--output-upload` per collegamenti QA
IOS distribuzione	`app_store`, `ad_hoc`	Non invia mai ad App Store

Per artefatti QA scaricabili, combinare debug Android con --no-playstore-upload --output-upload Esegui la lettura dell'URL con build last-output.

Note sulla sicurezza

Preferisci le regole di protezione dell'ambiente (GitHub) o le variabili protette (GitLab) per release i costrutti che inviano i risultati ai negozi.
Non mettere le password di firma nelle workflow inputs – solo nelle segrete/variabili.
Limita chi può eseguire le workflow con i ruoli del repository e le autorizzazioni di team (è richiesta l'accesso di scrittura su GitHub). La protezione di branch da sola non controlla Esegui la workflow; aggiungi un controllo di autorizzazione all'interno della workflow se solo un gruppo più ristretto può avviare i costrutti.

GitHub Azioni (setup completo) Esporta credenziali e invia/etichetta flussi di lavoro.

Auto OTA o Nativo Lascia che CI sceglie l'aggiornamento in tempo reale vs Capgo Costruisci su ogni push.

Attiva tramite Webhook Chiamare le stesse pipeline da un dashboard amministrativo tramite HTTP.