Gérer les builds de développement et de production avec GitHub actions

Ce tutoriel porte sur l'hébergement GitHub, mais vous pouvez l'adapter avec un petit ajustement à toute autre plateforme CI/CD.

Préface

Assurez-vous d’avoir d’abord ajouté votre application Capacitor à Capgo ; ce tutoriel se concentre uniquement sur la phase d’upload.

Convention de commit

Commencez par suivre la convention de commit commits conventionnels` cela aidera les outils à comprendre comment incrémenter le numéro de version ; cela s'apprend en 5 min.

actions GitHub pour les tags

Ensuite, vous devez créer votre première action GitHub pour automatiser le build et la création de tags.

Créez un fichier à ce chemin : .github/workflows/bump_version.yml

avec ce contenu :

name: Bump version

on:
  push:
    branches:
      - main
      - development

jobs:
  bump-version:
    if: "!startsWith(github.event.head_commit.message, 'chore(release):')"
    runs-on: ubuntu-latest
    name: "Bump version and create changelog with standard version"
    steps:
      - name: Check out
        uses: actions/checkout@v6
        with:
          fetch-depth: 0
          filter: blob:none
          token: '${{ secrets.PERSONAL_ACCESS_TOKEN }}'
      - name: Git config
        run: |
          git config --local user.name "github-actions[bot]"
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
      - name: Create bump and changelog
        if: github.ref == 'refs/heads/main'
        run: npx capacitor-standard-version
      - name: Create bump and changelog
        if: github.ref != 'refs/heads/main'
        run: npx capacitor-standard-version --prerelease alpha
      - name: Push to origin
        run: |
          CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
          remote_repo="https://${GITHUB_ACTOR}:${{ secrets.PERSONAL_ACCESS_TOKEN }}@github.com/${GITHUB_REPOSITORY}.git"
          git pull $remote_repo $CURRENT_BRANCH
          git push $remote_repo HEAD:$CURRENT_BRANCH --follow-tags --tags

Cela créera un tag pour chaque commit de votre branche principale, ainsi qu'une alpha release pour development, et enfin une entrée dans le changelog pour chaque commit dans CHANGELOG.md.

Pas d'inquiétude si vous n'avez pas ce fichier, il sera créé pour vous.

Pour que cela fonctionne, vous devez créer un TOKEN D'ACCÈS PERSONNEL et l'ajouter à vos GitHub secrets comme PERSONAL_ACCESS_TOKEN.

C'est nécessaire pour que la CI puisse commiter le changelog et l'incrémentation de version.

Lors de la création du token, choisissez comme expiration never et comme scope repo.

Fixez le version clé dans votre package.json fichier. Utilisez pour cela la dernière version publiée sur le store.

Ce n'est nécessaire que la première fois ; ensuite, les outils le maintiennent à jour.

Vous pouvez maintenant commiter ces deux fichiers et voir votre premier tag apparaître dans GitHub !

capacitor-standard-version est le package qui fait la magie ; par défaut, il met aussi à jour votre numéro de version sur Android et iOS

actions GitHub pour le build

Créez un fichier à ce chemin : .github/workflows/build.yml

avec ce contenu :

name: Build source code and send to Capgo

on:
  push:
    tags:
      - '*'
      
jobs:
  deploy:
    runs-on: ubuntu-latest
    name: "Build code and release"
    steps:
      - name: Check out
        uses: actions/checkout@v6
      - name: Install dependencies
        id: install_code
        run: npm i
      - name: Build
        id: build_code
        run: npm build
        env:
          MY_ENV_VAR: ${{ secrets.MY_ENV_VAR }}
      - name: Create Release Alpha
        if: "contains(github.ref, '-alpha.')"
        id: create_release_prepro
        run: npx @capgo/cli@latest bundle upload -a ${{ secrets.CAPGO_TOKEN }} -c development
      - name: Create Release Production
        if: "!contains(github.ref, '-alpha.')"
        id: create_release_prod
        run: npx @capgo/cli@latest bundle upload -a ${{ secrets.CAPGO_TOKEN }} -c production

Cela installera et compilera votre dépendance avant de l'envoyer vers Capgo.

Si votre commande de build est différente, vous pouvez la modifier dans l' build_code étape.

Si vous avez besoin d'une variable d'environnement, utilisez MY_ENV_VAR et configurez le secret dans les paramètres de votre projet GitHub, puis Secrets, puis l'action GitHub.

Pour que l’upload Capgo fonctionne, vous devez récupérer votre clé API pour Capgo et l’ajouter dans le secret de votre dépôt GitHub comme CAPGO_TOKEN.

Vous pouvez maintenant committer ces deux fichiers et voir apparaître votre première version dans Capgo !

L’ajout du commit générera un nouveau build Capacitor pour les canaux de production et de développement.

Vous devriez ajouter vos tests à l’étape de build Ionic pour vous assurer que votre code fonctionne.

Accédez à votre dashboard Capgo et vérifiez le build qui vient d’apparaître : votre système CI/CD est en place.

Continuez avec Gérer les builds de développement et de production avec des actions GitHub

Si vous utilisez Gérer les builds de développement et de production avec GitHub actions pour planifier le routage des canaux et le déploiement progressif, connectez-l’avec Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Solution de bêta-test pour le workflow produit de la Solution de bêta-test, et Solution de ciblage de version pour le workflow produit de la Solution de ciblage de version.