Trigger Native Builds von der CI-Benutzeroberfläche

Ein Setup-Vorschlag mit den Installationsanweisungen und der vollständigen Markdown-Anleitung für diesen Plugin kopieren.

Manchmal benötigen Sie ein signiertes iOS- oder Android-Binary ohne ein PR zu mergen oder einen Release-Tag zu schneiden – ein QA-Build, ein Store-Resubmit oder ein TestFlight-Einsatz. Jeder große code-Host kann von seiner Web-UI aus eine Pipeline starten. Diese Anleitung zeigt, wie man die UI mit Capgo Build verbindet.

Wat Sie erhalten

Kein Git-Zeremoniell

Klicken Sie auf ‘Workflow ausführen / Pipeline ausführen’. Capgo Build kompiliert aus der von Ihnen ausgewählten Branch.

Sichere Eingaben

Plattform und Build-Modus nutzen konstruierte Auswahlmöglichkeiten, wenn der Host sie unterstützt (GitHub / Bitbucket / Azure). GitLab-Variablen bleiben editierbar pro Ausführung, es sei denn, Sie definieren Pipeline-Eingaben mit options.

Selbe Geheimnisse wie CI

Wiederholen Sie die Capgo Build-Kredentials, die bereits in Ihrem Repository vorhanden sind. Neues wird auf Laptops nicht benötigt.

Voraussetzungen

Capgo Build funktioniert einmal lokal oder in CI – siehe Anmeldung von Geheimnissen, die bereits im Host vorhanden sind (für __CAPGO_KEEP_0__,
exportieren Sie mit dem GitHub und export with the CLI and gh secret set -f)
CAPGO_TOKEN als verschlüsselter Geheimcode / CI-Variablen gespeichert

GitHub Aktionen

GitHub’s Aktionen die Registerkarte kann jeden Workflow starten, der sich als workflow_dispatch.

1. Hinzufügen des Workflows

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. Ausführen von der Benutzeroberfläche

Öffnen Sie das GitHub Repository im Browser
Gehe zu Aktionen
Wähle Capgo Build (Manuell)
Klicke Ablaufplan ausführen
Wähle den Zweig, die Plattform und die Modus
Bestätige Ablaufplan ausführen

Jeder mit Schreibberechtigung Kann Zugriff einen Build starten. Die Beispielkarte release läuft zu einem GitHub-Umgebung benannt production — erstelle diese Umgebung und füge erforderliche Rezensenten hinzu, damit Builds auf Wartung warten. Ohne environment: auf dem Job, gelten Umgebungs-Schutzregeln nie.

GitLab CI

GitLab kann einen Job ausführen, wenn Bau → Pipelines → Pipeline ausführen der Job für diese Zweig 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

GitLab-Projekt öffnen
Zu Bau → Pipelines → Pipeline ausführen
Zweig wählen
Optional können Sie PLATFORM / BUILD_MODE Variablen für diese Ausführung festlegen
Dann klicken Sie auf die Play-Taste auf capgo_native_manual

when: manual verhindert das Job-Beenden bei jedem Push; die Web-Oberfläche (oder ein Pipeline-Auslöser-Token) startet es auf Anforderung.

Bitbucket Pipelines

Verwenden Sie einen benutzerdefinierten Pipeline, damit die Bitbucket-Oberfläche Variablen übergeben kann:

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 von Pipelines → Pipeline ausführen → Benutzerdefiniert: capgo-native-buildSpeichern Sie CAPGO_TOKEN und das Signierungs-Material unter Repository-Einstellungen → Pipelines → Repository-Variablen.

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 und pr: none halten Sie die Pipeline so, dass sie nicht automatisch bei CI/PR-Ausführungen gestartet wird, sondern von Pipelines → Pipeline ausführen (oder einem Webhook). Wenn das Projekt Azure Repos-Branch-Policies verwendet, die diese Pipeline in der Warteschlange platzieren, deaktivieren Sie diese Policy separat. Fügen Sie CAPGO_TOKEN und Signierwerte zu einer Variablegruppe hinzu, die als geheim markiert ist.

Empfohlene Eingaben

Eingabe	Vorgeschlagene Werte	Hinweise
Plattform	`ios`, `android`, `both`	Matrix wenn `both`
Modus	`debug`, `release`	Debug + `--output-upload` für QA-Links
iOS-Verteilung	`app_store`, `ad_hoc`	Ad-hoc sendet nie an den App Store

Für herunterladbare QA-Artikel kombinieren Sie den Debug-Android-Modus mit --no-playstore-upload --output-upload und lesen Sie die URL mit build last-output.

Sicherheitshinweise

Verwenden Sie Umgebungsrichtlinien zum Schutz der Umgebung (GitHub) oder geschützte Variablen (GitLab) für release Bauprozesse, die sich an den Stores anmelden.
Legen Sie keine Signierungs-Passwörter in der Workflow- inputs — nur in Geheimnissen/Variablen.
Beschränken Sie die Anzahl der Personen, die Workflows ausführen können, mit Repository-Rollen und Team-Berechtigungen (Schreibzugriff ist erforderlich auf GitHub). Die Schutz von Branchen reicht nicht aus, um die Ausführung von Workflows zu kontrollieren Workflow ausführen; fügen Sie eine Autorisierungsprüfung innerhalb des Workflows hinzu, wenn nur eine enger Gruppe Bauprozesse starten darf.

GitHub Aktionen (vollständige Einrichtung) Kredenziale exportieren und push/Tag-Workflows ausführen.

Auto OTA oder Native Lassen Sie CI live Update gegen Capgo Build auf jeden Push entscheiden.

Über Webhook auslösen Rufen Sie die gleichen Pipelines über HTTP von einem Admin-Dashboard auf.