Saltar al contenido
Capgo - Crea, publica y actualiza apps Capacitor Capgo

Dispara Native Builds desde la interfaz de CI

A veces necesitas un binario firmado de iOS o Android sin hacer un merge de un PR o crear un tag de release: un build para QA, un resubmit a la tienda o un TestFlight puntual. Casi cualquier host de code permite iniciar un pipeline desde su interfaz web. Esta guía te enseña cómo conectar esa interfaz con Capgo Build.

Lo que obtienes

Sección titulada “Qué obtienes”

Sin ceremonias de Git

Haz clic en Run workflow / Run pipeline. Capgo Build compila desde la rama que elijas.

Inputs seguros

La plataforma y el modo de build usan opciones restringidas si el host lo permite (GitHub / Bitbucket / Azure). Las variables de GitLab siguen siendo editables en cada ejecución a menos que definas entradas del pipeline con options.

Mismos secrets que en CI

Reutiliza las credenciales de Capgo Build de tu repo. Sin configurar nada en laptops.

Requisitos

Sección titulada “Prerrequisitos”

Acciones de GitHub

Sección titulada “GitHub Actions”

de GitHub Acciones la pestaña puede iniciar cualquier workflow que declare workflow_dispatch.

1. Añade el workflow

Sección titulada “1. Añadir el workflow”
.github/workflows/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. Ejecútalo desde la UI

Sección titulada “2. Ejecutarlo desde la UI”
  1. Abre el repositorio de GitHub en el navegador
  2. Ve a Acciones
  3. Selecciona Capgo Build (Manual)
  4. Haz clic Ejecutar workflow
  5. Elige la rama, plataforma y modo
  6. Confirmar Ejecutar workflow

Cualquiera con permisos de escritura puede iniciar un build. El ejemplo mapea release a un entorno GitHub llamado production — crea ese entorno y añade revisores para que los builds esperen aprobación. Sin environment: en ejecución, las reglas de protección de entorno nunca se aplican.

GitLab CI

Sección titulada “GitLab CI”

GitLab puede ejecutar un job desde Build → Pipelines → Ejecutar pipeline cuando el job 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. Ve a Build → Pipelines → Ejecutar pipeline
  3. Elige la rama
  4. Configura opcionalmente PLATFORM / BUILD_MODE las variables para esta ejecución
  5. Inicia el pipeline y haz clic en el botón play en capgo_native_manual

when: manual evita que el job se ejecute en cada push; la web UI (o un token de trigger del pipeline) lo inicia bajo demanda.

Bitbucket Pipelines

Sección titulada “Bitbucket Pipelines”

Usa un pipeline personalizado para que la UI 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útalo desde Pipelines → Ejecutar pipeline → Custom: capgo-native-build. Guarda CAPGO_TOKEN y el material de firma en Configuración del repositorio → Pipelines → Variables del 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 mantén el pipeline fuera de las ejecuciones automáticas de CI/PR para que comience desde Pipelines → Ejecutar pipeline (o un webhook). Si el proyecto usa políticas de rama de Azure Repos que encolan este pipeline, desactiva esa política por separado. Añade CAPGO_TOKEN y los valores de firma a un grupo de variables marcado como secret.

Sección titulada “Recommended Inputs”
EntradaValores sugeridosNotas
Plataformaios, android, bothMatriz de ejecución both
Mododebug, releaseDebug + --output-upload para enlaces de QA
distribución iOSapp_store, ad_hocAd-hoc nunca se envía a App Store

Para artefactos de QA descargables, combina debug Android con --no-playstore-upload --output-upload y lee la URL con build last-output.

Notas de seguridad

Sección titulada “Security Notes”
  • Prefiere reglas de protección de entorno (GitHub) o variables protegidas (GitLab) para release builds que se envían a las tiendas.
  • No incluyas contraseñas de firma en el workflow inputs — solo en secrets/variables.
  • Limita quién puede ejecutar workflows con roles de repositorio y permisos de equipo (se requiere acceso de escritura en GitHub). La protección de ramas por sí sola no controla Ejecutar workflow; añade un check de autorización en el workflow si solo un grupo reducido puede iniciar builds.
Sección titulada “Guías relacionadas”
GitHub Actions (configuración completa) Exportar credenciales y workflows de push/tag.
OTA automático o nativo Deja que CI elija entre live update y Capgo Build en cada push.
Disparar vía Webhook Ejecuta los mismos pipelines desde un dashboard de administración vía HTTP.