Native Builds über die CI-UI triggern

Manchmal benötigt man eine signierte iOS- oder Android-Binary, ohne einen PR mergen oder ein Release-Tag erstellen zu müssen – etwa für einen QA-Build, einen Store-Resubmit oder einen einmaligen TestFlight. Fast jeder code Host kann eine Pipeline direkt über sein Web-UI starten. Dieser Guide zeigt dir, wie du dieses UI mit Capgo Build verbindest.

Deine Vorteile

Kein Git-Overhead

Klicke auf Run workflow / Run pipeline. Capgo Build wird aus dem gewählten Branch kompiliert.

Sichere Inputs

Plattform und Build-Modus nutzen vordefinierte Auswahlmöglichkeiten, sofern der Host dies unterstützt (GitHub / Bitbucket / Azure). GitLab-Variablen bleiben pro Run editierbar, es sei denn, du definierst Pipeline-Inputs mit options.

Gleiche Secrets wie in der CI

Nutze die Capgo Build-Credentials aus deinem Repo. Keine neuen Configs auf Laptops nötig.

Voraussetzungen

• Capgo Build läuft lokal oder in der CI — siehe Erste Schritte
• Signing-Secrets sind bereits auf dem Host vorhanden (für GitHub, exportieren mit CLI und gh secret set -f)
• CAPGO_TOKEN gespeichert als masked Secret / CI-Variable

GitHub Aktionen

GitHubs Aktionen Tab kann jeden Workflow starten, der dies deklariert workflow_dispatch.

1. Workflow hinzufügen

.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

2. In der UI ausführen

1. Öffne das GitHub-Repository im Browser
2. Gehe zu Aktionen
3. Wähle Capgo Build (manuell)
4. Klicken Workflow ausführen
5. Branch, Plattform und Modus wählen
6. Bestätigen Workflow ausführen

Jeder mit schreiben kann einen Build starten. Das Beispiel mappt release Runs auf eine GitHub Umgebung namens production — erstelle diese Umgebung und füge erforderliche Reviewer hinzu, damit Store-Builds auf die Freigabe warten. Ohne environment: im Job greifen Environment-Protection-Rules nie.

Tipp

Bevorzugst du API oder ein anderes Tool statt des Buttons? Nutze gh workflow run oder schau dir Builds via Webhook triggern für repository_dispatch.

GitLab CI

GitLab kann einen Job ausführen, Build → Pipelines → Pipeline ausführen sobald der Job für diesen Branch verfügbar ist.

# 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. Öffne das GitLab-Projekt
2. Gehe zu Build → Pipelines → Pipeline ausführen
3. Wähle den Branch
4. Optional festlegen: PLATFORM / BUILD_MODE Variablen für diesen Run
5. Starte die Pipeline und klicke dann auf den Play-Button bei capgo_native_manual

when: manual verhindert, dass der Job bei jedem Push ausgelöst wird; die Web-UI (oder ein Pipeline-Trigger-Token) startet ihn bei Bedarf.

Bitbucket Pipelines

Nutze eine Custom Pipeline, damit die Bitbucket UI Variablen übergeben kann:

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"

Ausführen über Pipelines → Pipeline ausführen → Custom: capgo-native-build. Speichere CAPGO_TOKEN und Signing-Material unter Repository-Einstellungen → Pipelines → Repository-Variablen.

Azure DevOps

azure-pipelines-capgo-manuell.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 und pr: none deaktiviere die Pipeline für automatische CI/PR-Runs, damit sie direkt über Pipelines → Pipeline ausführen (oder einen Webhook). Falls das Projekt Azure Repos Branch Policies nutzt, die diese Pipeline in eine Warteschlange stellen, deaktiviere diese Policy separat. Füge CAPGO_TOKEN und Signing-Werte einer als Secret markierten Variable Group hinzu.

Empfohlene Inputs

Input	Empfohlene Werte	Notizen
Plattform	ios, android, both	Matrix: wann both
Modus	debug, release	Debug + --output-upload für QA-Links
iOS-Distribution	app_store, ad_hoc	Ad-hoc wird nie an den App Store gesendet

Für downloadbare QA-Artefakte kombinieren Sie Debug Android mit --no-playstore-upload --output-upload und lesen Sie die URL mit build last-output.

Sicherheitshinweise

• Bevorzugen Sie Environment Protection Rules (GitHub) oder geschützte Variablen (GitLab) für release Builds, die an Stores gesendet werden.
• Keine Signing-Passwörter im Workflow speichern, inputs — nur in Secrets/Variablen.
• Beschränke die Workflow-Ausführung über Repository-Rollen und Team-Berechtigungen (Schreibzugriff auf GitHub erforderlich). Branch Protection allein reicht nicht aus, Workflow ausführen; füge eine Autorisierungsprüfung im Workflow hinzu, falls nur eine kleinere Gruppe Builds starten darf.

Verwandte Guides

GitHub Actions (Full Setup) Credentials exportieren und Workflows pushen/taggen.

Auto OTA oder Native CI bei jedem Push zwischen live update und Capgo Build wählen lassen.

Trigger per Webhook auslösen Rufe dieselben Pipelines über HTTP aus einem Admin-Dashboard auf.