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

La mayoría de las Capacitor versiones son solo JavaScript y deben enviarse como una actualización en vivo. Algunos cambios afectan la __CAPGO_KEEP_0__ nativa y requieren un nuevo binario desde __CAPGO_KEEP_0__ Build.Guía de construcción de code Esta guía muestra cómo hacer que las acciones de Capgo, GitLab CI o cualquier otra plataforma de CI/CD tomen la ruta correcta 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 Build

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 por aire no puede actualizar esos dispositivos de manera segura.

releaseType compara metadatos de paquetes nativos (Capacitor/plugins de Cordova y versiones). No ve cada edición 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 para la compatibilidad de dependencias — los ejemplos a continuación hacen ambas cosas.

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

Consejo

Configuración de la puerta de enlace para 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

• 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 Opciones de actualización en vivo de Capacitor: o subir manualmente o utilizar una estrategia de actualización en vivo que funcione para usted. Si está buscando una alternativa a la actualización en vivo de Capacitor, considere la actualización en vivo de Appflow o Capawesome. Si necesita ayuda para elegir la mejor opción para su proyecto, consulte nuestra página de preguntas frecuentes sobre actualizaciones en vivo o contacte con nuestros expertos en consultoría. | Si está buscando una alternativa a la actualización en vivo de Capacitor, considere la actualización en vivo de Appflow o Capawesome. Si necesita ayuda para elegir la mejor opción para su proyecto, consulte nuestra página de preguntas frecuentes sobre actualizaciones en vivo o contacte con nuestros expertos en consultoría. | Si está buscando una alternativa a la actualización en vivo de Capacitor, considere la actualización en vivo de Appflow o Capawesome. Si necesita ayuda para elegir la mejor opción para su proyecto, consulte nuestra página de preguntas frecuentes sobre actualizaciones en vivo o contacte con nuestros expertos en consultoría. | Si necesita ayuda para elegir la mejor opción para su proyecto, consulte nuestra página de preguntas frecuentes sobre consultoría. | Si está buscando una alternativa a la actualización en vivo de Capacitor, considere la actualización en vivo de Appflow o Capawesome. Si necesita ayuda para elegir la mejor opción para su proyecto, consulte nuestra página de preguntas frecuentes sobre actualizaciones en vivo o contacte con nuestros expertos en consultoría.
• 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 llevarse a cabo con una estrategia de actualización en vivo que funcione para usted. (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 OTA, subir con --fail-on-incompatible y --auto-min-update-version.
5. Si native, ejecuta Capgo Build, luego sube el paquete correspondiente con --auto-min-update-version de esta manera, el canal avanza con los metadatos nativos. No utilice ese upload de base — los nuevos paquetes nativos deben diferir. Consulte --fail-on-incompatible Native + OTA Channel Workflow para la FAQ del canal. __CAPGO_KEEP_0__ Acciones

GitHub Acciones

Un flujo de trabajo que controla las rutas nativas, luego se ramifica en 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 \
            --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 Build.

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 se envíe un binario nativo, suba el conjunto de recursos 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 caja de conchas 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.

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 al condicional de su plataforma (o mantener un solo trabajo con una consola ifcomo 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 ramificar 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-compilación, por lo que ramifique con una caja de comandos 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' }

Rutas Filtros (Optimización de Velocidad Opcional)

Los filtros de rutas son una optimización de costos, no un sustituto de la comprobación Capgo. Prefiere excluir rutas de 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 utilizas una lista de permisos en lugar de eso, incluye todos los inputs que leen tus compilaciones web y nativas, 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 de 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 de JS aún devuelve native.
3. Una vez que los usuarios instalan el nuevo binario, los commits posteriores de JavaScript solo 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 Iniciar construcción de Capgo desde una consola de administración o cualquier cliente HTTP.