Avvia costruzioni native dal UI di CI

Copia un avviso 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 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 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 di GitLab rimangono modificabili 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.

Requisiti

Capgo Compila una volta localmente o in CI — vedi Avvio rapido
Segnala 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 __CAPGO_KEEP_0__ 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

Apri il repository GitHub nel browser
Vai a Azioni
Seleziona 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 denominato production — crea quell'ambiente e aggiungi i revisori richiesti affinché le build attendano l'approvazione. Senza environment: l'accesso al lavoro, 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

Apri il progetto GitLab
Vai a Costruisci → Pipeline → Esegui pipeline
Scegli il ramo
Seleziona optionalmente PLATFORM / BUILD_MODE variabili per questa esecuzione
Avvia la pipeline, quindi clicca sul pulsante play capgo_manuale nativo

when: manual preventa il lancio del job con ogni push; la UI web (o un token di attivazione della pipeline) lo avvia su richiesta.

Pipelines di Bitbucket

Usa una pipeline personalizzata affinché l'UI 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"

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

Microsoft 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 contexto: Pagina/Area: Sito web di marketing Capgo. Ruolo: Etichetta breve UI o elemento di navigazione. Visualizzato in: pagina trust.astro. Chiave di messaggio `e` (E). mantenere la pipeline fuori dai run automatici CI/PR affinché inizi da Pipelines → Esegui pipeline CAPGO_TOKEN (o un webhook). Se il progetto utilizza le politiche di rami di Azure Repos che attivano questa pipeline, disabilita separatamente quella politica. Aggiungi

e valori di firma a un gruppo di variabili contrassegnato come segreto.

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`	Ad-hoc non invia mai a App Store

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

Nota 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 dei team (è richiesta la scrittura su GitHub). La protezione della branca da sola non controlla Esegui 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 il 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.