Desencadena compilaciones nativas desde la interfaz de CI

Copia un prompt de configuración con los pasos de instalación y la guía de markdown completa para este plugin.

A veces necesitas un binario iOS o Android firmado sin fusionar un PR o cortar una etiqueta de liberación — una construcción de QA, una resubmisión de tienda o una construcción de TestFlight. Cada host principal 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

No hay ceremonia de Git

Haz clic en Ejecutar flujo de trabajo / Ejecutar pipeline. Capgo 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

Reutiliza los Capgo credenciales de compilación ya presentes en tu repositorio. Nada nuevo en laptops.

Requisitos previos

Capgo Compila una vez localmente o en CI — consulte Inicio rápido
Las firmas de secretos ya presentes en el host (para GitHub, export con CLI y gh secret set -f)
CAPGO_TOKEN almacenado como un secreto mascarado / variable de CI

GitHub Acciones

GitHub’s Acciones la pestaña de Acciones de __CAPGO_KEEP_0__ puede iniciar cualquier flujo de trabajo que declare workflow_dispatch.

1. Agregar el flujo de trabajo

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 IU

Abre el repositorio GitHub en el navegador
Vaya a Acciones
Seleccione Capgo Build (Manual)
Haga clic Ejecuta flujo de trabajo
Seleccione la rama, plataforma y modo
Confirme Ejecuta flujo de trabajo

Cualquiera con escribir puede iniciar un proceso de compilación. Los mapas de muestra release se ejecuta a un GitHub Entorno llamado production — cree ese entorno y agregue los revisores necesarios para que los builds esperen la aprobación. Sin environment: en el trabajo, las reglas de protección del entorno nunca se aplican.

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

Abrir el proyecto de GitLab
Ir a Construir → Pipelines → Ejecutar pipeline
Elegir la rama
Opcionalmente establecer PLATFORM / BUILD_MODE variables para esta ejecución
Ejecutar la pipeline, luego hacer clic en el botón de reproducción capgo_manual_nativo

when: manual evita que el trabajo dispare en cada push; la interfaz de usuario web (o un token de disparo de pipeline) lo inicia a demanda.

Pipelines de Bitbucket

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

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"

Ejecutar desde Pipelines → Ejecutar pipeline → Personalizado: capgo-build_nativoalmacenar CAPGO_TOKEN y material de firma bajo Configuración de repositorio → Pipelines → Variables de repositorio.

Azure DevOps

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 (o un webhook). Si el proyecto utiliza políticas de rama de Azure Repos que ponen en cola esta canalización, desactive esa política por separado. Agregue CAPGO_TOKEN y valores de firma a un grupo de variables marcado como secreto.

Entradas recomendadas

Entrada	Valores sugeridos	Nota
Plataforma	`ios`, `android`, `both`	Cuadrícula cuando `both`
Modo	`debug`, `release`	Depuración + `--output-upload` para enlaces de QA
distribución de iOS	`app_store`, `ad_hoc`	Nunca se envía a App Store

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

Notas 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 a 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 ramas sola no controla 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.

GitHub Acciones (configuración completa) Exportar credenciales y enviar flujos de trabajo.

Auto OTA o Nativo Deje que la CI elija la actualización en vivo vs Capgo Compilar en cada empuje.

Activar mediante Webhook Llamar a los mismos pipelines desde una consola de administración sobre HTTP.