Build et release automatiques avec GitLab

Ce tutoriel se concentre sur GitLab CI, mais vous pouvez l'adapter avec quelques ajustements à n'importe quelle autre plateforme CI/CD.

Préface

Assurez-vous d'avoir d'abord ajouté votre application à 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.

GitLab CI pour les tags

Ensuite, vous devez créer votre premier GitLab 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

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
        run: npx capacitor-standard-version
      - 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 générera une release pour chaque commit de votre branche principale, et ajoutera une entrée au changelog pour chaque commit de la branche principale dans CHANGELOG.md.

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

Pour que cela fonctionne, créez un TOKEN D'ACCÈS PERSONNEL et ajoutez-l’à vos variables GitLab CI/CD comme PERSONAL_ACCESS_TOKEN.

Ceci est nécessaire pour permettre à la CI de commit le changelog.

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

Enfin, pour que l'outil sache où votre version est sauvegardée, vous devez créer le fichier .cz.toml à la racine de votre dépôt.

Et ajoutez ceci à l'intérieur :

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$major.$minor.$patch$prerelease"
version = "0.11.5"
version_files = [
    "package.json:version",
    ".cz.toml"
]

Définissez la version dans ce fichier de la même manière que celle de votre package.json fichier.

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 !

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 run build
        env: # Remove both lines  if you don't need it
          FIREBASE_CONFIG: ${{ secrets.FIREBASE_CONFIG }} # Example of env var coming from a secret
      - name: Create Release
        id: create_release
        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.

Pour que cela 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 commiter ces deux fichiers et voir votre premier tag apparaître dans GitHub !

Ajouter le commit générera un nouveau build pour le canal de production.

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

Allez sur votre dashboard Capgo pour vérifier votre build qui vient d'apparaître ; vous avez maintenant votre système CI/CD.

Si vous voulez que tous vos utilisateurs reçoivent la mise à jour dès qu'elle est disponible, allez dans votre canal et réglez-le sur public.

Continuer avec le build et la release automatiques via Gitlab

Si vous utilisez Build et release automatiques avec GitLab pour planifier l'automatisation CI/CD, et le connecter avec CI/CD Capgo pour le workflow produit dans le CI/CD de Capgo, Capgo Native Build pour le workflow produit dans les Native Builds de Capgo, Intégrations Capgo pour le workflow produit dans les intégrations de Capgo, Intégration CI/CD pour le détail d'implémentation dans l'intégration CI/CD, et Intégration GitHub Actions pour les détails d'implémentation de l'intégration GitHub Actions.