Elige automáticamente la actualización en vivo o la compilación nativa

La mayoría de las Capacitor versiones son solo JavaScript y deben enviarse como una actualización en vivo. Algunos cambios afectan el __CAPGO_KEEP_0__ nativo y requieren un nuevo binario desde __CAPGO_KEEP_0__ Build.Guía de code Build Esta guía muestra cómo hacer que Capgo Actions, GitLab CI o cualquier otra plataforma de CI/CD elija el camino correcto en cada empuje — sin que un humano decida.. 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.

Sección titulada “La Decisión”

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 significa que los paquetes nativos coinciden con lo que ya está vivo en el canal. native significa que se cambió un plugin, la versión de Capacitor o otra dependencia nativa — un paquete de actualización por aire no puede actualizar esos dispositivos de manera segura.

releaseType compara metadatos de paquetes nativos (Capacitor/plugins de Cordova y versiones). No hace ver cada edición bajo , o ios/, android/. Bloquee esas rutas en Git primero, luego utilice capacitor.config.*para compatibilidad de dependencias — los ejemplos a continuación hacen ambas cosas. releaseType para

Ver Compatibilidad nativa Consulte las reglas completas y el manual en la bundle compatibility tabla.

Consejo

Ponga una puerta de seguridad en cada pipeline de producción en releaseType . Es más barato que adivinar, y evita enviar una actualización en vivo que hace que los dispositivos con la versión nativa anterior se caigan.

Requisitos previos

• su aplicación Capgo registrada y una Capgo __CAPGO_KEEP_1__ clave Capgo API key en CI secretos como CAPGO_TOKEN
• en Actualizaciones en vivo subir funcionando (bundle upload) — vea en Integración CI/CD
• en Capgo Credenciales de construcción en CI si espera trabajos nativos — vea en GitHub Acciones o en ¿Qué acciones puedo tomar? Puedo utilizar la integración de CI/CD de Capgo para subir actualizaciones en vivo. También puedo utilizar la integración de Appflow o Capawesome. Puedo consultar con un especialista de Capgo para obtener más información sobre cómo elegir la mejor opción para mi proyecto.
• en Credenciales production)
• en Un canal que ya existe y coincide con la producción (los ejemplos utilizan metadata en Canal en el --auto-min-update-version en estrategia de manera que cada subida pueda llevar (una vez):

npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata

¿Cómo debería funcionar la Pipeline?

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. Compilar activos web de manera habitual.
2. Si el commit toca ios/, android/, o capacitor.config.*, forzar el camino nativo.
3. De lo contrario, preguntar a Capgo releaseType ¿Si el commit es seguro para OTA?
4. Si OTACarga con --fail-on-incompatible y --auto-min-update-version.
5. Si nativerealiza Capgo Build, luego sube el paquete correspondiente con --auto-min-update-version así el canal avanza con los metadatos nativos. No haga ese upload de base — los nuevos paquetes nativos deben diferir. Consulte Native + OTA Channel Workflow --fail-on-incompatible para la FAQ del canal. __CAPGO_KEEP_0__ Acciones Sección titulada “__CAPGO_KEEP_0__ Acciones”

GitHub Actions

Un flujo de trabajo que bloquea las rutas nativas, luego bifurca en releaseType:

github/trabajos/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 \
            --auto-min-update-version

  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: |
          # Channel must already be on metadata (see Prerequisites above)
          npx @capgo/cli@latest bundle upload com.example.app \
            --channel production \
            --auto-min-update-version

Sustituir com.example.app y conectar los secretos de firma como se describe en GitHub Acciones para Capgo Construcción.

Nota

--fail-on-incompatible pertenece solo al trabajo OTA. Después de que coloque el canal en la metadata estrategia, mantenga --auto-min-update-version en cada carga (OTA y baseline nativa). Después de que un binario nativo envíe, cargue el conjunto de paquetes correspondiente con --auto-min-update-version y sin --fail-on-incompatible así más tarde releaseType verifica las nuevas paquetes nativos.

GitLab CI

GitLab evalúa rules cuando se crea el pipeline, así que rama con una shell if dentro de un trabajo de despliegue (o genera un pipeline hijo dinámico si necesitas trabajos de matriz nativos separados):

.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 \
          --auto-min-update-version
      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

Guardar CAPGO_TOKEN y Capgo Variables de firma de compilación como variables de CI/CD protegidas/ocultas.

Otras plataformas de CI

Los mismos tres pasos funcionan en cualquier lugar:

Paso	Comando
Veredicto	npx @capgo/cli@latest bundle releaseType APP_ID --channel production
Ruta OTA	npx @capgo/cli@latest bundle upload APP_ID --channel production --fail-on-incompatible --auto-min-update-version
Ruta nativa	npx @capgo/cli@latest build request APP_ID --platform ios (o android) --build-mode release

Asignar el código de salida de la consola / stdout a las condiciones de su plataforma (o mantener un solo trabajo con una consola if, como GitLab arriba):

• Azure Pipelines — establezca una variable de salida desde un paso de script, luego utilice condition: eq(variables['releaseType'], 'OTA')
• Bitbucket Pipelines — escriba RELEASE_TYPE=… para $BITBUCKET_PIPELINES_VARIABLES_PATHdeclararlo bajo output-variablesy dividir posteriormente los pasos con condition: state: RELEASE_TYPE == "OTA" (los artefactos de archivo solos no pueden impulsar condition)
• CircleCI — when se evalúa en tiempo de configuración, por lo que divida con una caja de conchas de tiempo de ejecución if o una configuración dinámica / continuación, no un valor de espacio de trabajo en when
• Jenkins — captura la salida estándar en una variable de entorno y utilízala when { environment name: 'RELEASE_TYPE', value: 'OTA' }

Filtros de rutas (Optimización de velocidad opcional)

Los filtros de rutas son una optimización de costos, no un sustituto de la Capgo verificación. Prefiere excluir rutas de solo documentación en lugar de mantener una lista de permisos frágil — las compilaciones web a menudo también dependen de vite.config.*, tsconfig*.json, y archivos de configuración de marco:

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

Si utiliza una lista de permisos en su lugar, incluya todos los inputs que leen las compilaciones web y nativas, no solo src/ y package.json.

Después de un Veredicto Nativo

Cuando CI elige la compilación nativa:

1. Capgo La compilación produce binarios firmados y puede enviarlos a TestFlight / Play (consulte configuración).
2. Subir el paquete JS correspondiente con --auto-min-update-version (estrategia de metadatos) para que los registros del canal capturen los nuevos paquetes nativos — de lo contrario, el próximo commit solo con JS aún devuelve native.
3. Una vez que los usuarios instalen el nuevo binario, los commits posteriores solo con JavaScript vuelven a OTA de nuevo.

Guías relacionadas

Compatibilidad nativa ¿Por qué Capgo devuelve OTA vs nativo y cómo bloquear subidas maliciosas?

Flujo de trabajo del canal NATIVO + OTA Canales de desarrollo/producto y cuándo dejar de usar --fail-on-incompatible para una base nativa intencional.

GitHub Acciones (Capgo Compilación) Secretos de firma y flujos de construcción nativa completa.

Desencadenar construcciones desde la interfaz de usuario de CI Ejecutar una construcción nativa a demanda desde GitHub, GitLab o Bitbucket.

Desencadenar construcciones mediante Webhook Disparar construcción de Capgo desde una consola de administración o cualquier cliente HTTP.