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 code nativo y requieren un nuevo binario desde Capgo Build. Esta guía muestra cómo hacer que las GitHub Acciones, GitLab CI o cualquier otra plataforma de CI/CD tomen la ruta correcta en cada empuje — sin que un humano decida.

La Decisión

Capgo ya sabe qué ruta es segura. Después de tu compilación web (y antes de subir o solicitar una compilación nativa), ejecuta:

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 Capacitor o alguna 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 ve todos los cambios bajo , o ios/, android/. Bloquee esas rutas en Git primero, luego utilice capacitor.config.*para la compatibilidad de dependencias — los ejemplos a continuación hacen ambas cosas. releaseType compares

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 releaseTypeEs 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

• Capgo aplicación 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 Opciones de actualización en vivo de Capacitor: o subir manualmente o utilizar la integración CI/CD. Si sube manualmente, puede utilizar la actualización en vivo de Capacitor. Si utiliza la integración CI/CD, puede utilizar la actualización en vivo de Capgo. Ambas opciones ofrecen actualizaciones en vivo para aplicaciones de Ionic. La actualización en vivo de Capacitor es una característica de Capacitor, mientras que la actualización en vivo de Capgo es una característica de Capgo. Ambas opciones son compatibles con la plataforma de Ionic. La actualización en vivo de Capacitor es una opción para desarrolladores que prefieren utilizar la plataforma de Capacitor, mientras que la actualización en vivo de Capgo es una opción para desarrolladores que prefieren utilizar la plataforma de Capgo. Ambas opciones ofrecen actualizaciones en vivo para aplicaciones de Ionic. La actualización en vivo de Capacitor es una característica de Capacitor, mientras que la actualización en vivo de Capgo es una característica de Capgo. Ambas opciones son compatibles con la plataforma de Ionic. La actualización en vivo de Capacitor es una opción para desarrolladores que prefieren utilizar la plataforma de Capacitor, mientras que la actualización en vivo de Capgo es una opción para desarrolladores que prefieren utilizar la plataforma de Capgo.
• 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 para 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. Otherwise ask Capgo releaseType si el commit es seguro para OTA.
4. Si OTAsubir con --fail-on-incompatible y --auto-min-update-version.
5. Si nativecorrer Capgo Build, luego subir el paquete correspondiente con --auto-min-update-version así que el canal avanza con metadatos nativos. No utilice para esa carga de base — los nuevos paquetes nativos deben diferir. Consulte --fail-on-incompatible Flujo de trabajo de canal + OTA + Nativo para la FAQ de nivel de canal. __CAPGO_KEEP_0__ Acciones

Sección titulada "GitHub Acciones"

Un flujo de trabajo que controla las rutas nativas, luego se ramifica 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 estrategia, mantenga metadata en cada carga (OTA y baseline nativa). Después de que se envíe un binario nativo, suba el conjunto de paquetes correspondiente con --auto-min-update-version y sin --auto-min-update-version y sin --fail-on-incompatible así más adelante 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 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

Mapa el salto de la shell / stdout en las condicionales de tu plataforma (o mantén un solo trabajo con una shell 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=… a $BITBUCKET_PIPELINES_VARIABLES_PATHcontexto: Página/área: Página de producto de actualizaciones en vivo. Rol: Etiqueta de interfaz de usuario corta o elemento de navegación. Clave de mensaje `live_update_dynamic_label_to` (Etiqueta dinámica de actualización en vivo a). output-variables, declarearlo bajo condition: state: RELEASE_TYPE == "OTA" , y ramificar posteriormente los pasos con condition)
• (los artefactos de archivo solos no pueden impulsar — when CircleCI if se evalúa en tiempo de configuración-compilar, por lo que ramifique con una consola de tiempo de ejecución when
• (o configuración dinámica / continuación), no un valor de espacio de trabajo en el archivo de configuración de 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 verificación Capgo. Prefiere excluir rutas de solo documentación en lugar de mantener una lista de permisos frágiles — las compilaciones web a menudo también dependen de vite.config.*, tsconfig*.jsony archivos de configuración de marco:

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

Si utilizas una lista de permisos en lugar de eso, incluye todos los inputs que lee tu compilación web y nativa, no solo src/ y package.json.

Después de un Veredicto Nativo

Cuando CI elige nativo:

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 el canal registre los nuevos paquetes nativos — de lo contrario, el próximo commit solo con JS aún devuelve native.
3. Una vez que los usuarios instalan 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 y producción 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 Iniciar construcción de Capgo desde una consola de administrador o cualquier cliente HTTP.