Déclenchez les builds natives depuis l'interface utilisateur CI

Copiez un prompt de configuration avec les étapes d'installation et la guide Markdown complet pour ce plugin.

Parfois, vous avez besoin d'un fichier binaire iOS ou Android signé sans fusionner un PR ou couper une étiquette de version — une build de QA, une resoumission dans une boutique ou une build TestFlight unique. Chaque hôte majeur code peut démarrer une pipeline à partir de son interface web. Ce guide montre comment connecter cette interface à Capgo Build.

Ce que vous obtenez

Aucune cérémonie Git

Cliquez sur Exécuter flux de travail / Exécuter pipeline. Capgo Build compile depuis la branche que vous choisissez.

Entrées sécurisées

La plateforme et le mode de construction utilisent des choix contraints où l'hôte les supporte (GitHub / Bitbucket / Azure). Les variables GitLab restent éditable par exécution sauf si vous définissez Entrées de pipeline avec options.

Mêmes secrets que CI

Réutilisez les Capgo crédentiels de construction déjà présents dans votre dépôt. Rien de nouveau sur les ordinateurs portables.

Prérequis

Capgo Build fonctionne une fois localement ou en CI — voir Prise en main
Les secrets de signature déjà présents sur l'hôte (pour GitHub, exportez avec le CLI et gh secret set -f)
CAPGO_TOKEN stocké sous forme de secret masqué / variable CI

GitHub Actions

GitHub’s Actions la case d’options peut démarrer n’importe quel flux de travail qui déclare workflow_dispatch.

1. Ajoutez le flux de travail

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. Exécutez-le depuis l'interface utilisateur

Ouvrez le GitHub repository dans le navigateur
Allez à Actions
Sélectionnez Capgo Build (manuel)
Cliquez Démarrez le flux de travail
Choisissez la branche, la plateforme et le mode
Confirmez Démarrez le flux de travail

Tout le monde avec l'écriture l'accès peut démarrer une build. Les exemples de cartes release s'exécute dans un GitHub Environnement nommé production — créez cet environnement et ajoutez les revendeurs requis afin que les builds attendent l'approbation. Sans environment: sur le poste, les règles de protection de l'environnement ne s'appliquent jamais.

GitLab CI

GitLab peut exécuter une tâche à partir de Éditer → Flux de travail → Exécuter le flux de travail lorsque la tâche 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

Ouvrir le projet GitLab
Allez à Éditer → Flux de travail → Exécuter le flux de travail
Choisissez la branche
Configurez optionnellement PLATFORM / BUILD_MODE des variables pour cette exécution
Exécuter le pipeline, puis cliquez ensuite sur le bouton de lecture sur capgo_native_manual

when: manual garde l'emploi de la tâche à chaque push ; l'interface web (ou un jeton de déclencheur de pipeline) le déclenche à la demande.

Pipelines Bitbucket

Utilisez un pipeline personnalisé afin que l'interface utilisateur Bitbucket puisse passer des 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"

Exécuter à partir de Pipelines → Exécuter la pipeline → Personnalisé : capgo-native-buildEnregistrez CAPGO_TOKEN et le matériau de signature sous Paramètres de dépôt → Pipelines → Variables de dépôt.

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 et pr: none contexte : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément de navigation court. Vu dans : page trust.astro. Clé de message `and` (Et). gardez le pipeline hors des exécutions automatiques CI/PR pour qu'il démarre à partir de Pipelines → Exécuter le pipeline CAPGO_TOKEN (ou un webhook). Si le projet utilise des politiques de branchement Azure Repos qui mettent en file d'attente ce pipeline, désactivez cette politique séparément. Ajoutez

et les valeurs de signature à un groupe de variables marqué secret.

Entrée	Valeurs suggérées	Remarques
Plateforme	`ios`, `android`, `both`	Matrice lorsque `both`
Mode	`debug`, `release`	Debug + `--output-upload` pour les liens QA
Distribution iOS	`app_store`, `ad_hoc`	Jamais soumis à l'App Store

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

Notes de sécurité

Préférez les règles de protection de l'environnement (GitHub) ou les variables protégées (GitLab) pour release les builds qui soumettent aux magasins.
N'insérez pas les mots de passe de signature dans le flux de travail inputs — seulement dans les secrets/variables.
Limitez les personnes qui peuvent exécuter des flux de travail avec les rôles de repository et les autorisations d'équipe (l'accès en écriture est requis sur GitHub). La protection de branch ne contrôle pas Exécuter le flux de travail; ajoutez une vérification d'autorisation en cours de flux de travail si seulement un groupe plus restreint peut démarrer les builds.

GitHub Actions (full setup) Exporter les informations d'identification et les flux de travail push/tag.

Auto OTA ou Native Laissez CI choisir l'actualisation en direct par rapport à Capgo Construction à chaque push.

Déclencher via Webhook Appeler les mêmes pipelines depuis un tableau de bord administrateur via HTTP.