Native Builds aus der CI-Oberfläche auslösen

Eine Setup-Vorlage mit den Installationsanweisungen und der vollständigen Markdown-Dokumentation für diesen Plugin kopieren.

Manchmal benötigen Sie ein signiertes iOS- oder Android-Binärdatei ohne das Merging eines PR oder das Erstellen eines Release-Tags — ein QA-Build, ein Wiederinserieren in den Store oder ein einmaliges TestFlight. Jeder wichtige code-Host kann eine Pipeline aus seiner Web-Oberfläche starten. Diese Anleitung zeigt, wie man die Oberfläche mit Capgo Build verbindet.

Was Sie erhalten

Keine Git-Zeremonie

Click Run workflow / Run pipeline. Capgo Build compiles from the branch you pick.

Sichere Eingaben

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

Gleiche Geheimnisse wie CI

Reuse the Capgo Build credentials already in your repo. Nothing new on laptops.

Voraussetzungen

Capgo-Bauarbeiten einmal lokal oder in CI — siehe Anmeldung von Geheimnissen, die bereits im Host (für __CAPGO_KEEP_0__,
exportieren Sie mit dem GitHub und exportieren Sie mit dem CLI und gh secret set -f)
CAPGO_TOKEN gespeichert als maskierte Geheimzahl / CI-Variablen

Abschnitt mit dem Titel „GitHub-Aktionen“

GitHub-Aktionen Aktionen Ein Tab kann jeden Workflow ausführen, 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 UI

Öffnen Sie den GitHub-Repository im Browser
Gehe zu Aktionen
Wähle Capgo Build (Manuell)
Klicken Workflow ausführen
Wählen Sie den Zweig, die Plattform und die Modus
Bestätigen Workflow ausführen

Jeder mit Schreiben Ein Build kann gestartet werden. Die Beispielkarten release läuft zu einem GitHub Umgebungsname production erstellen Sie das Umfeld und fügen Sie erforderliche Rezensenten hinzu, damit Builds auf Genehmigung warten können. Ohne environment: während der Arbeit gelten Umweltschutzregeln nie.

GitLab CI

GitLab kann eine Aufgabe ausführen, wenn Bau → Pipelines → Pipeline ausführen wenn die Aufgabe für den entsprechenden 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

Öffnen Sie das GitLab-Projekt
Gehe zu Build → Pipelines → Pipeline ausführen
Wähle den Zweig
Optional setzen Sie PLATFORM / BUILD_MODE Variablen für diese Ausführung
Führen Sie den Pipeline, klicken Sie dann auf die Play-Schaltfläche auf capgo_native_handbuch

when: manual keppt die Aufgabe von jedem Push aus; die Web-Oberfläche (oder ein Pipeline-Trigger-Token) startet sie auf Anforderung.

Bitbucket Pipelines

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

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-build. Speichern Sie CAPGO_TOKEN und das Signierungsmaterial 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 von automatischen CI/PR-Ausführungen ab, damit sie von Pipelines → Pipeline ausführen (oder einem Webhook). Wenn das Projekt Azure Repos-Branch-Policies verwendet, die diese Pipeline anstellen, deaktivieren Sie diese Policy separat. Fügen Sie CAPGO_TOKEN und Werte für eine geheime Variablegruppe zu speichern.

Empfohlene Eingaben

Vorschläge	Vorgeschlagene Werte	Plattform
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-Artefakte kombinieren Sie Debug-Android mit --no-playstore-upload --output-upload und lesen Sie die URL mit build last-output.

Sicherheitshinweise

Verwenden Sie bevorzugt Umgebungs-Schutzregeln (GitHub) oder geschützte Variablen (GitLab) für release Bauprozesse, die in den Stores einreichen.
Verwenden Sie keine Signierungs-Passwörter in Workflows inputs — nur in Geheimnissen/Variablen.
Beschränken Sie, wer Workflows ausführen darf, mit Repository-Rollen und Teamberechtigungen (Schreibzugriff ist erforderlich auf GitHub). Die Schutzfunktion für Branchen reicht allein nicht aus. Workflow ausführen; fügen Sie eine Autorisierungsprüfung innerhalb des Workflows hinzu, wenn nur eine enger Gruppe Builds starten darf.

GitHub Actions (full setup) Exportiere Anmeldeinformationen und push/Tag-Workflows.

Auto OTA oder Native Lassen Sie CI live update gegen Capgo wählen, um auf jedem Push zu bauen.

__CAPGO_KEEP_0__ Rufen Sie dieselben Pipelines über HTTP von einem Admin-Dashboard aus auf.