Trigger Native Builds von der CI-Benutzeroberfläche

Einen 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 das Merging eines PR oder das Schneiden eines Release-Tags — ein QA-Build, ein Store-Resubmit oder ein einmaliges TestFlight. Jeder große code-Host kann von seiner Web-UI aus einen Pipeline starten. Diese Anleitung zeigt, wie man die UI mit Capgo Build verbindet.

Wat Sie erhalten

Keine Git-Zeremonie

Klicken Sie auf Workflow ausführen / Pipeline ausführen. Capgo Die Build-Kompilierung erfolgt von der von Ihnen ausgewählten Branch.

Sichere Eingaben

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

Selbe Geheimnisse wie CI

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

Voraussetzungen

Die Capgo Build-Arbeit wird einmalig lokal oder in CI durchgeführt – siehe Einführung
Geheimnisse, die bereits im Host gespeichert sind (für GitHub, export mit der CLI und gh secret set -f)
CAPGO_TOKEN als maskierte Geheimzahl / CI-Variablen gespeichert

GitHub Aktionen

GitHub's Aktionen die Registerkarte Aktionen kann jeden Workflow starten, der 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)
Klicken Sie Workflow ausführen
Wählen Sie den Zweig, die Plattform und den Modus
Bestätigen Workflow ausführen

Jeder mit schreiben der 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-Schutz-Regeln gelten nie.

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

GitLab-Projekt öffnen
Gehe zu Build → Pipelines → Pipeline ausführen
Zweig auswählen
Optional können Sie PLATFORM / BUILD_MODE Variablen für diese Ausführung festlegen
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:

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 Unterzeichnungsdaten 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 context: Seite/ Bereich: Capgo-Marketing-Website. Rolle: Kurzer UI-Label oder Navigationspunkt. Gesehen in: Seite trust.astro. Nachrichtenschlüssel `und` (Und). halten Sie die Pipeline von automatischen CI/PR-Ausführungen ab, damit sie von Pipelines → Pipeline ausführen CAPGO_TOKEN (oder eine 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 Unterzeichnungsdaten 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` zur QA-Link
iOS-Verteilung	`app_store`, `ad_hoc`	Ad-hoc stellt nie zum App Store

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

Sicherheitshinweise

Umgebungsschutzregeln (GitHub) oder geschützte Variablen (GitLab) für release Bauprozesse, die in den Stores eingereicht werden.
Legen Sie keine Signierungs-Passwörter in Workflows 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.

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

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

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