Auto-Wahl zwischen Live-Update oder Native Build

Die meisten Capacitor-Versionen sind JavaScript-basiert und sollten als lebendige Aktualisierung bereitgestellt werden. Live-UpdateEinige Änderungen betreffen native code-Pakete und erfordern ein neues Binär von code Build. Diese Anleitung zeigt, wie man es ermöglicht, dass Capgo-Actions, GitLab CI oder jede andere CI/CD-Plattform die richtige Route auf jeden Push auswählen – ohne dass ein Mensch entscheidet.. This guide shows how to make GitHub Actions, GitLab CI, or any other CI/CD platform pick the correct path on every push — without a human deciding.

Abschnitt mit dem Titel “Die Entscheidung”

Capgo already knows which path is safe. After your web build (and before you upload or request a native build), run:

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      ship with bundle upload
# → native   ship with Capgo Build

OTA Die Entscheidung native bedeutet ein Plugin, Capacitor Version oder andere native Abhängigkeit geändert wurde — eine über die Luft liegende Bundle kann diese Geräte nicht sicher aktualisieren.

releaseType vergleicht native Paketmetadata (Capacitor/Cordova-Plugins und -Versionen). Es tut das nicht sieht nicht jede Änderung unter ios/, android/, oder capacitor.config.*Blockiere diese Pfade in Git zuerst, dann verwenden Sie releaseType für Abhängigkeitskompatibilität — die folgenden Beispiele tun beides.

Siehe Native-Kompatibilität für die vollständigen Regeln und die Handanweisung bundle compatibility Tabelle.

Tip

Jeden Produktionspipeline auf releaseType Es ist günstiger als das Raten, und es vermeidet das Bereitstellen eines lebendigen Updates, das auf Geräten mit älteren nativen Binärcode stürzt.

Voraussetzungen

• Capgo Anwendung registriert und ein __CAPGO_KEEP_1__ Capgo-Schlüssel Capgo API key Live-Updates-Upload funktioniert ( CAPGO_TOKEN
• ) — siehebundle upload) — see CI/CD-Integration
• Capgo Build-Zugangsdaten in CI, wenn native Jobs erwartet werden — siehe GitHub Actions oder Zugangsdaten
• Ein Kanalname, der der Produktionsumgebung entspricht (Beispiele verwenden production)

Wie die Pipeline funktionieren sollte

flowchart TD
  A[Push / merge] --> B[Install + web build]
  B --> C["bundle releaseType"]
  C -->|OTA| D["bundle upload"]
  C -->|native| E["build request iOS + Android"]
  E --> F[Store / TestFlight / Play]

1. Web-Assets wie gewohnt bauen.
2. Wenn der Commit ios/, android/, oder capacitor.config.*zwinge den nativen Pfad.
3. Ansonsten fragen Sie Capgo releaseType ob der Commit OTA-sicher ist.
4. Wenn OTAdas Bundle (mit --fail-on-incompatible als Sicherheitsbügel) hochladen.
5. Wenn nativeCapgo Build ausführen, dann das entsprechende Bundle hochladen mit --auto-min-update-version so dass sich die Metadaten des Kanals fortlaufend (verwenden Sie die Metadatenstrategie) ergeben. Verwenden Sie nicht benutzen --fail-on-incompatible für diesen Basisupload — die neuen native Pakete sollen sich unterscheiden.

GitHub Aktionen

Ein Workflow, der native Pfade einschränkt, dann auf releaseType:

github/workflows/capgo-release.yml

name: Capgo Release

on:
  push:
    branches: [main]

jobs:
  decide:
    runs-on: ubuntu-latest
    outputs:
      release_type: ${{ steps.verdict.outputs.type }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'

      - run: npm ci
      - run: npm run build

      - name: Decide OTA vs native
        id: verdict
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
        run: |
          BEFORE="${{ github.event.before }}"
          if [ -z "$BEFORE" ] || [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
            BEFORE="$(git rev-parse HEAD~1 2>/dev/null || echo '')"
          fi
          if [ -z "$BEFORE" ] || git diff --name-only "$BEFORE" "${{ github.sha }}" \
            | grep -qE '^(ios/|android/|capacitor\.config\.)'; then
            TYPE=native
            echo "Native path/config changed (or no prior commit) — forcing native"
          else
            TYPE=$(npx @capgo/cli@latest bundle releaseType com.example.app --channel production | tr -d '[:space:]')
          fi
          echo "type=$TYPE" >> "$GITHUB_OUTPUT"
          echo "Capgo release type: $TYPE"

  live_update:
    needs: decide
    if: needs.decide.outputs.release_type == 'OTA'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - name: Upload live update
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
        run: |
          npx @capgo/cli@latest bundle upload com.example.app \
            --channel production \
            --fail-on-incompatible

  native_build:
    needs: decide
    if: needs.decide.outputs.release_type == 'native'
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        platform: [ios, android]
    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 ${{ matrix.platform }}
        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: |
          npx @capgo/cli@latest build request com.example.app \
            --platform ${{ matrix.platform }} \
            --build-mode release

  native_bundle:
    needs: [decide, native_build]
    if: needs.decide.outputs.release_type == 'native'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - name: Upload bundle for new native baseline
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
        run: |
          # One-time: channel set production --disable-auto-update metadata
          npx @capgo/cli@latest bundle upload com.example.app \
            --channel production \
            --auto-min-update-version

Ersetzen com.example.app und die Signaturgeheimnisse wie beschrieben in GitHub Aktionen für Capgo Build.

Hinweis

--fail-on-incompatible gehört nur zur OTA-Aufgabe. Nachdem ein natives Binärpaket abgeschickt wurde, laden Sie das entsprechende Bundle hoch. --auto-min-update-version später releaseType Überprüfen Sie, ob die neuen native Pakete vorhanden sind.

GitLab CI

GitLab überprüft rules wenn der Pipeline erstellt wird, also die Zweig mit einer Shell if innerhalb eines Bereitstellungsjobs (oder generieren Sie ein dynamisches Kind-Pipeline wenn Sie separate native Matrix-Jobs benötigen): .gitlab-ci.yml

Zur Zwischenablage kopieren

image: node:24

stages:
  - build
  - deploy

variables:
  APP_ID: com.example.app
  CHANNEL: production

build_web:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
      - node_modules/
    expire_in: 1 hour
  only:
    - main

deploy:
  stage: deploy
  needs: [build_web]
  script:
    - |
      BEFORE="${CI_COMMIT_BEFORE_SHA:-}"
      if [ -z "$BEFORE" ] || [ "$BEFORE" = "0000000000000000000000000000000000000000" ]; then
        BEFORE="$(git rev-parse HEAD~1 2>/dev/null || echo '')"
      fi
      if [ -z "$BEFORE" ] || git diff --name-only "$BEFORE" "$CI_COMMIT_SHA" \
        | grep -qE '^(ios/|android/|capacitor\.config\.)'; then
        TYPE=native
      else
        TYPE=$(npx @capgo/cli@latest bundle releaseType "$APP_ID" --channel "$CHANNEL" | tr -d '[:space:]')
      fi
      echo "Capgo release type: $TYPE"
      if [ "$TYPE" = "OTA" ]; then
        npx @capgo/cli@latest bundle upload "$APP_ID" \
          --channel "$CHANNEL" \
          --fail-on-incompatible
      elif [ "$TYPE" = "native" ]; then
        npx cap sync
        npx @capgo/cli@latest build request "$APP_ID" --platform ios --build-mode release
        npx @capgo/cli@latest build request "$APP_ID" --platform android --build-mode release
        npx @capgo/cli@latest bundle upload "$APP_ID" \
          --channel "$CHANNEL" \
          --auto-min-update-version
      else
        echo "Unexpected release type: $TYPE" >&2
        exit 1
      fi
  only:
    - main

Speicherplatz CAPGO_TOKEN und Capgo Build-Zertifizierungsvariablen als maskiert/geschützte CI/CD-Variablen speichern.

Sonstige CI-Plattformen

Die gleichen drei Schritte funktionieren überall:

Schritt	Befehl
Ausgang	npx @capgo/cli@latest bundle releaseType APP_ID --channel production
OTA-Pfad	npx @capgo/cli@latest bundle upload APP_ID --channel production --fail-on-incompatible
Nativer Pfad	npx @capgo/cli@latest build request APP_ID --platform ios (oder android) --build-mode release

Die Ausgabe der Shell-Exit- / STDOUT in die Bedingungen Ihres Plattformen (oder behalten Sie ein einzelnes Job mit einer Shell ifwie GitLab oben):

• Azure Pipelines — eine Ausgabeverbinder von einem Skript-Schritt setzen, dann verwenden condition: eq(variables['releaseType'], 'OTA')
• Bitbucket Pipelines — schreiben RELEASE_TYPE=… zu $BITBUCKET_PIPELINES_VARIABLES_PATH, es unter output-variables, und mit condition: state: RELEASE_TYPE == "OTA" (Dateiartefakte allein können nicht condition)
• CircleCI — when am Konfigurations-Kompilierungszeitpunkt ausgewertet, also mit einer Laufzeit-Shell if (oder dynamische Konfiguration / Fortsetzung), nicht mit einem Workspace-Wert in when
• Jenkins — die Ausgabe in eine Umgebungsvariable speichern und verwenden when { environment name: 'RELEASE_TYPE', value: 'OTA' }

Schaltflächen für Pfadfilter (Optional Speedup)

Pfadfilter sind eine Kostenoptimierung, nicht ein Ersatz für die Capgo-Überprüfung. Vorziehen Sie die Ausschließung von Dokumentationspfaden anstatt die Aufrechterhaltung einer fragilen Zulassliste — Web-Builds hängen oft auch von vite.config.*, tsconfig*.json, und Konfigurationsdateien von Frameworks ab:

on:
  push:
    branches: [main]
    paths-ignore:
      - '**.md'
      - 'docs/**'
      - '.github/**'

Wenn Sie eine Zulassliste verwenden, sollten Sie alle Eingaben berücksichtigen, die Ihre Web- und native Builds lesen, nicht nur src/ und package.json.

Nach einer nativen Entscheidung

Wenn CI native wählt:

1. Capgo Build erzeugt signierte Binärdateien und kann diese bei TestFlight / Play einreichen (siehe Konfiguration).
2. Laden Sie die entsprechende JS-Bundle mit --auto-min-update-version (Metadatenstrategie) damit die Kanäle die neuen native Pakete aufzeichnen — ansonsten kehrt der nächste JS-only Commit wieder native.
3. Zurück. OTA Wieder.

Zugehörige Anleitungen

Native Kompatibilität Warum Capgo OTA vs native zurückgibt und wie man schlechte Uploads blockiert.

GitHub Aktionen (Capgo Build) Signierungsschlüssel und vollständige native Build-Workflows.

Trigger Builds aus der CI-Oberfläche Runnen Sie einen native Build auf Anforderung von GitHub, GitLab oder Bitbucket.

Trigger Builds über Webhook Feuern Sie den Capgo-Build aus einer Admin-Oberfläche oder einem beliebigen HTTP-Client.