Déclenchez les builds natives depuis l'interface utilisateur de 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 relier cette interface à Capgo Build.

Ce que vous obtenez

Aucune cérémonie Git

Appuyez sur Exécuter le flux de travail / Exécuter la pipeline. Capgo La compilation se produit à partir de la branche que vous sélectionnez.

Entrées sûres

Utilisation des choix contraints pour la plateforme et le mode de build, où le hôte les supporte (GitHub / Bitbucket / Azure). Les variables GitLab restent éditable par run, à moins que vous définissiez Entrées de pipeline avec options.

Même secrets que CI

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

Prérequis

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

GitHub Actions

GitHub’s Actions la rubrique Actions peut démarrer tout 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 dépôt GitHub dans votre navigateur
Allez à Actions
Sélectionnez Capgo Build (manuel)
Cliquez Exécutez le workflow
Sélectionnez le branchement, le système d'exploitation et le mode
Confirmez Exécutez le workflow

Toute personne avec écrire l'accès peut démarrer une build. Les exemples de cartes release s'exécutent 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 un job à partir de Étape de construction → Flux de travail → Exécuter le flux de travail 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

Ouvrir le projet GitLab
Allez à Étape de construction → Flux de travail → Exécuter le flux de travail
Sélectionner la branche
Configurer optionnellement PLATFORM / BUILD_MODE des variables pour cette exécution
Démarrer le flux de travail, puis cliquez sur le bouton de lecture sur capgo_manuel native

when: manual empêche le travail de se lancer à chaque push ; l'interface web (ou un token 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 une pipeline → Personnalisé : capgo-manuel-build stocker CAPGO_TOKEN et matériau de signature sous Paramètres de dépôt → Flux de travail → 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 : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément UI court. Vu dans : page trust.astro. Clé de message `and` (Et). gardez le flux hors des exécutions automatiques CI/PR pour qu'il démarre à partir de Flux de travail → Exécuter le flux de travail CAPGO_TOKEN (ou un webhook). Si le projet utilise des politiques de branchement Azure Repos qui mettent en file d'attente ce flux de travail, 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 debug Android avec --no-playstore-upload --output-upload et lire 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 (setup complet) Exporter les informations d'identification et pousser les workflows.

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

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