Native Builds über die CI-Benutzeroberfläche auslösen

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 einmaliges TestFlight. Jeder wichtige code-Host kann von seiner Web-UI aus eine Pipeline starten. Diese Anleitung zeigt Ihnen, wie Sie die UI mit Capgo Build verbinden können.

Wat Sie erhalten

Keine Git-Zeremonie

Klicken Sie auf Ausführen des Workflows / Ausführen der Pipeline. Capgo Die Build-Kompilierung erfolgt aus der von Ihnen ausgewählten Branch.

Sichere Eingaben

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

Die gleichen Geheimnisse wie CI

Wiederverwenden Sie die Capgo Build-Anmeldeinformationen, die bereits in Ihrem Repository vorhanden sind. Kein Neues auf Laptops.

Voraussetzungen

• Capgo Die Build-Arbeit funktioniert einmal lokal oder in CI — siehe Anleitung zum Starten
• Geheimnisse, die bereits im Host signiert sind (für GitHub, export mit der CLI und gh secret set -f)
• CAPGO_TOKEN als verschlüsselter Geheimcode / CI-Variablen gespeichert

GitHub Aktionen

GitHub‘s Aktionen die Registerkarte Aktionen kann jeden Workflow starten, der workflow_dispatch.

1. Hinzufügen des Workflows

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

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

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

Tip

Vorziehen Sie die API oder eine andere Werkzeug, um auf den Button zu klicken? Verwenden Sie gh workflow run oder sehen Sie Trigger Builds über Webhook für repository_dispatch.

GitLab CI

GitLab kann einen Job ausführen, wenn Build → 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

1. GitLab-Projekt öffnen
2. Hierhin Build → Pipelines → Pipeline ausführen
3. Zweig wählen
4. Optional können Sie PLATFORM / BUILD_MODE Variablen für diese Ausführung festlegen
5. Pipeline starten und dann auf die Play-Taste klicken capgo_native_manual

when: manual verhindert, dass die Aufgabe bei jedem Push abläuft; die Web-Oberfläche (oder ein) Pipeline-Auslöser-Token) startet sie auf Anforderung.

Bitbucket Pipelines

Verwenden Sie einen benutzerdefinierten Pipeline, damit die Bitbucket-Oberfläche 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 von Pipelines → Pipeline ausführen → Benutzerdefiniert: capgo-native-build. Speichern CAPGO_TOKEN und Unterzeichnungsmaterial Repository-Einstellungen → Pipelines → Repository-Variablen.

Azure DevOps

azure-pipelines-capgo-manual.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 context: Seite/ Bereich: Capgo-Marketing-Website. Rolle: Kurzer UI-Label oder Navigationselement. Gesehen in: Seite trust.astro. Nachrichten Schlüssel `und` (Und). halten Sie die Pipeline von automatischen CI/PR-Ausführungen aus, damit sie von Pipelines → Pipeline ausführen CAPGO_TOKEN (oder einem Webhook). Wenn das Projekt Azure Repos-Branch-Policies verwendet, die diese Pipeline in der Warteschlange anlegen, deaktivieren Sie diese Policy separat. Fügen Sie

und Unterzeichnungswerte zu einer Variablegruppe hinzu, die als geheim markiert ist.

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

Sicherheitshinweise

• Verwenden Sie Umgebungs-Schutzregeln (GitHub) oder geschützte Variablen (GitLab) für release Bauprozesse, die in den Stores eingereicht werden.
• Stellen Sie keine Signierungs-Passwörter in der Workflow- inputs nur in Geheimnissen/Variablen.
• Einschränken Sie die Personen, die Workflows ausführen dürfen, mit Repository-Rollen und Team-Berechtigungen (Schreibzugriff ist erforderlich auf GitHub). Die Schutz von Branchen reicht allein nicht aus, um Workflow ausführen; fügen Sie eine Autorisierungsprüfung innerhalb des Workflows hinzu, wenn nur eine enger Gruppe Bauprozesse starten darf.

Zugehörige Anleitungen

GitHub Actions (full setup) Exportieren Sie Anmeldeinformationen und pushen Sie/teilen Sie Workflows.

Auto OTA oder Native Lassen Sie CI die lebendige Aktualisierung gegenüber der Capgo-Erstellung auf jedem Push wählen.

Auslösen über Webhook Rufen Sie die gleichen Pipelines über HTTP von einem Administrationsdashboard auf.