Saltar al contenido
Capgo - Live Updates for Capacitor Apps Capgo

Desencadena compilaciones nativas desde la IU de CI

A veces necesitas un binario iOS o Android firmado sin fusionar una PR o cortar una etiqueta de liberación — una compilación de QA, una resubmisión de tienda o una prueba de TestFlight. Cada host mayor de code puede iniciar una canalización desde su interfaz de usuario web. Esta guía muestra cómo cablear esa interfaz a Capgo Build.

Lo que obtienes

Sección titulada “Lo que obtienes”

No hay ceremonia Git

Haz clic en Ejecutar flujo de trabajo / Ejecutar canalización. Capgo Build compila desde la rama que elijas.

Entradas Seguras

Plataforma y modo de compilación utilizan opciones limitadas donde el host las admite (GitHub / Bitbucket / Azure). Las variables de GitLab permanecen editables por ejecución a menos que definas Entradas de pipeline con options.

Los mismos secretos que CI

Reuse the Capgo Build credentials already in your repo. Nothing new on laptops.

Requisitos previos

Título de la sección “Requisitos previos”

GitHub Acciones

Sección titulada “GitHub Acciones”

GitHub’s Acciones tab puede iniciar cualquier flujo de trabajo que declare workflow_dispatch.

1. Agregar el flujo de trabajo

Sección titulada “1. Agregar el flujo de trabajo”
.github/trabajos/capgo-build-manual.yml
name: Capgo Build (Manual)


on:
  workflow_dispatch:
    inputs:
      platform:
        description: Platform to build
        required: true
        default: both
        type: choice
        options: [ios, android, both]
      mode:
        description: Build mode
        required: true
        default: debug
        type: choice
        options: [debug, release]
      ref_note:
        description: Optional note for the run summary
        required: false
        type: string


jobs:
  build:
    runs-on: ubuntu-latest
    environment: ${{ inputs.mode == 'release' && 'production' || 'build-debug' }}
    strategy:
      fail-fast: false
      matrix:
        platform: ${{ fromJSON(inputs.platform == 'both' && '["ios","android"]' || format('["{0}"]', inputs.platform)) }}
    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
        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: |
          EXTRA=""
          if [ "${{ inputs.mode }}" = "debug" ] && [ "${{ matrix.platform }}" = "android" ]; then
            EXTRA="--no-playstore-upload --output-upload"
          fi
          npx @capgo/cli@latest build request com.example.app \
            --platform ${{ matrix.platform }} \
            --build-mode ${{ inputs.mode }} \
            $EXTRA

2. Ejecutarlo desde la interfaz de usuario

2. Ejecutar desde la interfaz de usuario
  1. Abra el repositorio GitHub en el navegador
  2. Vaya a Acciones
  3. Seleccione Capgo Construcción (Manual)
  4. Haga clic Ejecutar flujo de trabajo
  5. Seleccione la rama, plataforma y modo
  6. Confirmar Ejecutar flujo de trabajo

Cualquiera con write puede iniciar una construcción. Los mapas de muestra release se ejecuta a un GitHub ambiente llamado production — cree ese ambiente y agregue los revisores requeridos para que las construcciones esperen la aprobación. Sin environment: en el trabajo, las reglas de protección del entorno nunca se aplican.

GitLab CI

Título de la sección “GitLab CI”

GitLab puede ejecutar un trabajo desde Construir → Pipelines → Ejecutar pipeline cuando el trabajo esté disponible para esa rama.

# Job fragment for .gitlab-ci.yml
stages:
  - build


variables:
  APP_ID: com.example.app
  PLATFORM: android   # override from Run pipeline UI
  BUILD_MODE: debug


capgo_native_manual:
  stage: build
  when: manual
  script:
    - npm ci
    - npm run build
    - npx cap sync "$PLATFORM"
    - |
      npx @capgo/cli@latest build request "$APP_ID" \
        --platform "$PLATFORM" \
        --build-mode "$BUILD_MODE"
  rules:
    # Actions / Pipelines UI → manual play button
    - if: '$CI_PIPELINE_SOURCE == "web"'
      when: manual
    # Pipeline trigger token / webhook → run automatically
    - if: '$CI_PIPELINE_SOURCE == "trigger"'
      when: on_success
    - when: never
  1. Abre el proyecto de GitLab
  2. Vaya a Construir → Pipelines → Ejecutar pipeline
  3. Elige la rama
  4. Opcionalmente establece PLATFORM / BUILD_MODE variables para esta ejecución
  5. Inicia el pipeline, luego haz clic en el botón de reproducción en capgo_native_manual

when: manual mantiene el trabajo desde que no se dispare en cada empuje; la interfaz web (o un) token de disparo de pipeline) lo inicia a demanda.

Bitbucket Pipelines

Sección titulada “Bitbucket Pipelines”

Utilice un pipeline personalizado para que la interfaz de Bitbucket pueda pasar variables:

bitbucket-pipelines.yml
pipelines:
  custom:
    capgo-native-build:
      - variables:
          - name: PLATFORM
            default: android
            allowed-values:
              - ios
              - android
          - name: BUILD_MODE
            default: debug
            allowed-values:
              - debug
              - release
      - step:
          name: Capgo Build
          image: node:24
          script:
            - npm ci
            - npm run build
            - npx cap sync "$PLATFORM"
            - npx @capgo/cli@latest build request com.example.app --platform "$PLATFORM" --build-mode "$BUILD_MODE"

Ejecútelo desde Pipelines → Ejecutar pipeline → Personalizado: capgo-native-buildAlmacenar CAPGO_TOKEN y material de firma bajo Configuración de repositorio → Pipelines → Variables de repositorio.

Azure DevOps

Sección titulada “Azure DevOps”
azure-pipelines-capgo-manual.yml
trigger: none   # disable CI push triggers
pr: none        # also disable PR triggers (GitHub/Bitbucket-backed projects)


parameters:
  - name: platform
    displayName: Platform
    type: string
    default: android
    values:
      - ios
      - android
  - name: buildMode
    displayName: Build mode
    type: string
    default: debug
    values:
      - debug
      - release


pool:
  vmImage: ubuntu-latest


steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '24.x'
  - script: |
      npm ci
      npm run build
      npx cap sync ${{ parameters.platform }}
      npx @capgo/cli@latest build request com.example.app \
        --platform ${{ parameters.platform }} \
        --build-mode ${{ parameters.buildMode }}
    env:
      CAPGO_TOKEN: $(CAPGO_TOKEN)
      # map other signing secrets from Library → Variable groups

trigger: none y pr: none mantenga la canalización fuera de ejecuciones automáticas de CI/PR para que comience desde Pipelines → Ejecutar canalización Si el proyecto utiliza políticas de rama de Azure Repos que programan esta canalización, desactive esa política por separado. Agregar CAPGO_TOKEN y valores de firma a un grupo de variables marcado como secreto.

Sección titulada “Entradas recomendadas”
EntradaValores sugeridosNotas
Plataformaios, android, bothCuando la matriz both
Mododebug, releaseDepuración + --output-upload para enlaces de QA
Distribución de iOSapp_store, ad_hocNunca se envía a la Tienda de Mac App

Para artefactos de QA descargables, combine la depuración de Android con --no-playstore-upload --output-upload y lee la URL con build last-output.

Nota de seguridad

Sección titulada “Nota de seguridad”
  • Preferir reglas de protección del entorno (GitHub) o variables protegidas (GitLab) para release los builds que se envían a tiendas.
  • No ponga contraseñas de firma en flujos de trabajo inputs – solo en secretos/variables.
  • Limitar quién puede ejecutar flujos de trabajo con roles de repositorio y permisos de equipo (se requiere acceso de escritura en GitHub). La protección de rama no controla solo Ejecutar flujo de trabajo; agregar una comprobación de autorización dentro del flujo de trabajo si solo un grupo más estrecho puede iniciar builds.
Sección titulada “Guías relacionadas”
GitHub Acciones (configuración completa) Exportar credenciales y flujos de trabajo de push/tag.
Auto OTA o Nativo Deje que CI elija live update vs Capgo. Construir en cada push.
Activar mediante Webhook Llame a las mismas pipelines desde una consola de administración mediante HTTP.