Déclencher des Native Build depuis l'interface CI

Parfois, vous avez besoin d'un binaire iOS ou Android signé sans fusionner de PR ni créer de tag de release — un build QA, une nouvelle soumission sur les stores ou un TestFlight ponctuel. Tous les principaux hôtes code peuvent lancer un pipeline depuis leur interface web. Ce guide explique comment relier cette interface à Capgo Build.

Ce que vous obtenez

Pas de cérémonie Git

Cliquez sur Run workflow / Run pipeline. Capgo Build compile à partir de la branche que vous choisissez.

Entrées sécurisées

La plateforme et le mode de build utilisent des choix restreints lorsque l'hôte le permet (GitHub / Bitbucket / Azure). Les variables GitLab restent modifiables par exécution, sauf si vous définissez les entrées du pipeline par options.

Mêmes secrets que la CI

Réutilisez les identifiants de build Capgo déjà présents dans votre repo. Rien de nouveau sur les ordinateurs.

Prerequisites

• Le build Capgo fonctionne déjà localement ou en CI — voir Prise en main
• Les secrets de signature sont déjà sur l'hôte (pour GitHub, exportez avec CLI et gh secret set -f)
• CAPGO_TOKEN stockés comme un secret masqué / une variable CI

GitHub Actions GitHub

de GitHub Actions onglet peut lancer n'importe quel workflow qui déclare workflow_dispatch.

1. Ajouter le 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. Lancer depuis l'interface

1. Ouvrez le dépôt GitHub dans votre navigateur
2. Accéder à Actions
3. Sélectionnez Build Capgo (manuel)
4. Cliquez Lancer le workflow
5. Choisissez la branche, la plateforme et le mode
6. Confirmer Lancer le workflow

Anyone with écriture et d'accès peut lancer un build. L'exemple mappe release les exécutions vers un environnement GitHub nommé production — créez cet environnement et ajoutez des reviewers pour que les builds de store attendent une approbation. Sans environment: sur le job, les règles de protection d'environnement ne s'appliquent jamais.

Astuce

Vous préférez utiliser API ou un autre outil pour cliquer sur le bouton ? Utilisez gh workflow run ou consultez Déclencher des builds via webhook pour repository_dispatch.

GitLab CI

GitLab peut exécuter un job depuis Build → Pipelines → Exécuter le pipeline lorsque le job est disponible pour cette branche.

# 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. Ouvrez le projet GitLab
2. Accéder à Build → Pipelines → Exécuter le pipeline
3. Choisissez la branche
4. Définissez optionnellement PLATFORM / BUILD_MODE les variables pour ce run
5. Lancez le pipeline, puis cliquez sur le bouton play de capgo_native_manual

when: manual évite que le job ne se déclenche à chaque push ; l'interface web (ou un token de déclenchement de pipeline) le lance à la demande.

Bitbucket Pipelines

Use a custom pipeline so the Bitbucket UI can pass 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"

Exécutez-le depuis Pipelines → Exécuter le pipeline → Custom : capgo-native-build. Store CAPGO_TOKEN et les éléments de signature sous Paramètres du dépôt → Pipelines → Variables du dépôt.

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 et pr: none désactivez le pipeline pour les exécutions automatiques de CI/PR afin qu'il démarre depuis Pipelines → Exécuter le pipeline (ou un webhook). Si le projet utilise des politiques de branche Azure Repos qui mettent ce pipeline en file d'attente, désactivez cette politique séparément. Ajoutez CAPGO_TOKEN et les valeurs de signature à un groupe de variables marqué comme secret.

Entrées recommandées

Saisie	Valeurs suggérées	Notes
Plateforme	ios, android, both	Matrix quand both
Mode	debug, release	Debug + --output-upload pour les liens QA
distribution iOS	app_store, ad_hoc	Ad-hoc n'est jamais soumis à l'App Store

Pour les artefacts QA téléchargeables, combinez le debug Android avec --no-playstore-upload --output-upload et lisez l'URL avec build last-output.

Notes de sécurité

• Privilégiez les règles de protection d'environnement (GitHub) ou les variables protégées (GitLab) pour release les builds soumis aux stores.
• Ne mettez pas de mots de passe de signature dans le workflow inputs — uniquement dans les secrets/variables.
• Limitez qui peut exécuter les workflows via les rôles du dépôt et les permissions d'équipe (un accès en écriture est requis sur GitHub). La protection de branche seule ne contrôle pas l'exécution du workflow; ajoutez un contrôle d'autorisation dans le workflow si seul un groupe restreint peut lancer des builds.

Guides associés

GitHub Actions (configuration complète) Exporter les credentials et les workflows de push/tag.

Auto OTA ou natif Laissez la CI choisir entre live update et Capgo Build à chaque push.

Déclencher via un webhook Appelez les mêmes pipelines depuis un dashboard admin via HTTP.