Choisir automatiquement la mise à jour en direct ou la construction native

La plupart des mises à jour Capacitor sont uniquement en JavaScript et devraient être envoyées comme une mise à jour en direct. Quelques changements touchent les __CAPGO_KEEP_0__ natifs et nécessitent un nouveau fichier binaire depuis __CAPGO_KEEP_0__ Build.code Build Cette guide montre comment faire en sorte que les actions Capgo, GitLab CI ou toute autre plateforme CI/CD prennent la bonne décision à chaque push — sans qu'un humain décide.. 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.

Section intitulée « La Décision »

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 signifie que les packages natifs correspondent à ce qui est déjà en ligne sur le canal. native signifie qu'un plugin, une version Capacitor ou une autre dépendance native a changé — un bundle par voie aérienne ne peut pas mettre à jour ces appareils de manière sécurisée.

releaseType compare les métadonnées des packages natifs (Capacitor / les plugins Cordova et leurs versions). Il fait pas voir chaque modification sous ios/, android/, ou capacitor.config.*. Bloquez ces chemins dans Git d'abord, puis utilisez releaseType pour la compatibilité des dépendances — les exemples ci-dessous font les deux.

Voir Compatibilité Native pour les règles complètes et le manuel bundle compatibility table.

Conseil

Gardez chaque pipeline de production sur releaseType. C'est moins cher que de deviner, et cela évite de livrer une mise à jour live qui fait planter les appareils toujours sur l'ancien binaire natif.

Prérequis

• Capgo application enregistrée et un Capgo API clé __CAPGO_KEEP_1__ dans les secrets de CI comme CAPGO_TOKEN
• Mises à jour en direct envoient des données (bundle upload) — voir Intégration CI/CD
• Capgo Les informations d'identification de construction si vous attendez des tâches natives — voir GitHub Actions ou Les informations d'identification
• La manière dont la chaîne de production devrait fonctionner production)

Section intitulée « La manière dont la chaîne de production devrait fonctionner »

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. Construire les actifs web comme d'habitude.
2. Si le commit touche ios/, android/, ou capacitor.config.*, forcez le chemin natif.
3. Sinon demandez à Capgo releaseType si le commit est sûr pour OTA.
4. Si OTA, téléchargez le bundle (avec --fail-on-incompatible comme garde-fou).
5. Si native, exécutez Capgo Build, puis téléchargez le bundle correspondant avec --auto-min-update-version afin que les métadonnées natives du canal soient mises à jour (utilisez la stratégie de métadonnées metadata strategy. Do ne pas --fail-on-incompatible utiliser

GitHub Actions

Sous-titre : « __CAPGO_KEEP_0__ Actions » 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

Copier dans le presse-papier com.example.app Remplacer et brancher les secrets de signature comme décrit dans « GitHub Actions pour la construction de Capgo ».

Remarque

--fail-on-incompatible appartient uniquement à la tâche OTA. Une fois un binaire natif expédié, téléchargez le bundle correspondant avec --auto-min-update-version ainsi plus tard releaseType vérifiez les nouvelles packages natifs.

GitLab CI

GitLab évalue rules lorsque la pipeline est créée, donc branch avec un shell if dans une seule tâche de déploiement (ou générer un pipeline enfant dynamique si vous avez besoin de jobs de matrice natifs séparés):

.gitlab-ci.yml

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

Stocker CAPGO_TOKEN and Capgo Build signing variables as masked/protected CI/CD variables.

Autres plateformes CI

Les mêmes trois étapes fonctionnent n'importe où :

Étape	Commande
Résultat	npx @capgo/cli@latest bundle releaseType APP_ID --channel production
Chemin OTA	npx @capgo/cli@latest bundle upload APP_ID --channel production --fail-on-incompatible
Chemin natif	npx @capgo/cli@latest build request APP_ID --platform ios (ou) android) --build-mode release

Cartographiez la sortie de la shell / stdout dans vos conditionnels de plateforme (ou maintenez un seul job avec une shell) if:)

• Azure Pipelines — définissez une variable de sortie à partir d'une étape de script, puis utilisez condition: eq(variables['releaseType'], 'OTA')
• Bitbucket Pipelines — écrivez RELEASE_TYPE=… à $BITBUCKET_PIPELINES_VARIABLES_PATHdéclarez-le sous output-variableset divisez les étapes ultérieures avec condition: state: RELEASE_TYPE == "OTA" (les artefacts de fichiers seuls ne peuvent pas faire condition)
• CircleCI — when est évalué en temps de compilation de la configuration, donc brancher avec un shell de temps d'exécution if (ou configuration dynamique / continuation), pas une valeur de bureau de travail dans when
• Jenkins — capturer la sortie standard dans une variable d'environnement et utiliser when { environment name: 'RELEASE_TYPE', value: 'OTA' }

Filtrings de chemins (Optimisation de vitesse facultative)

Les filtres de chemin sont une optimisation de coût, pas un substitut pour la vérification Capgo. vite.config.*, tsconfig*.jsonPréférez exclure les chemins de documentation uniquement plutôt que de maintenir une liste d'autorisation fragile — les builds web dépendent souvent également de

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

Copier dans le presse-papier src/ Si vous utilisez une liste d'autorisation au lieu, incluez tous les entrées que vos builds web et natifs lisent, pas seulement package.json.

et (contexte : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `et` (Et). )

Lorsque CI choisit la version native :

1. Capgo La construction produit des binaires signés et peut soumettre à TestFlight / Play (voir configuration).
2. Téléchargez le bundle JS correspondant avec --auto-min-update-version (stratégie de métadonnées) afin que le canal enregistre les nouveaux packages natifs — sinon le prochain commit uniquement en JavaScript revient native.
3. Une fois les utilisateurs ont installé le nouveau binaire, les commits JavaScript ultérieurs retournent à OTA Encore une fois.

Guides connexes

Compatibilité native Pourquoi Capgo retourne OTA plutôt que la version native et comment bloquer les téléchargements malveillants.

GitHub Actions (Capgo Build) Flux de construction et de signature de secrets.

Déclencher les constructions à partir de l'interface de l'outil CI. Déclencher une construction native à la demande à partir de GitHub, GitLab ou Bitbucket.

Déclencher les constructions via Webhook. Déclencher la construction Capgo à partir d'un tableau de bord administrateur ou tout client HTTP.