Construction automatique et déploiement avec Gitlab

Cette tutrice se concentre sur le CI GitLab, mais vous pouvez l'adapter avec un petit ajustement à tout autre plateforme CI/CD.

Avant-propos

Assurez-vous d'avoir ajouté votre application en premier lieu à Capgo, cette tutrice se concentre uniquement sur la phase d'upload.

Convention de commit

Tout d'abord, vous devez commencer à suivre la convention de commit. Commits conventionnelsCeci aidera les outils à comprendre comment mettre à jour le numéro de version, ce sera de 5 minutes à l'apprendre.

CI GitLab pour tag

Ensuite, vous devez créer votre premier GitLab pour qu'il crée automatiquement et crée un tag.

Créez un fichier à cette emplacement : .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

This will release a tag for every commit in your main branch. And add a changelog entry for each commit in the main branch in __CAPGO_KEEP_0__ CHANGELOG.md.

Ne vous inquiétez pas si vous n'avez pas ce fichier, il vous sera créé.

Pour que cela fonctionne, créez un PERSONAL ACCESS TOKEN et ajoutez-le à vos variables GitLab CI/CD comme PERSONAL_ACCESS_TOKEN.

Cela est nécessaire pour permettre au CI de commiter le changelog.

Lorsque vous créez le jeton, choisissez l'expiration comme never et le champ d'accès comme repo.

Enfin, pour permettre à l'outil de comprendre 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"
]

Fixez la version dans ce fichier comme celle que vous avez dans votre package.json fichier.

Cela n'est nécessaire que la première fois, puis les outils mettront à jour automatiquement.

Vous pouvez maintenant commiter ces deux fichiers et voir votre premier tag apparaitre dans GitHub!

GitHub actions pour la construction

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 construira votre dépendance avant de l'envoyer à Capgo.

Si votre commande de construction est différente, vous pouvez la modifier dans l'étape. build_code Pour que cela fonctionne, vous devez obtenir votre clé __CAPGO_KEEP_0__ pour __CAPGO_KEEP_1__, l'ajouter dans les secrets de votre repository __CAPGO_KEEP_0__

To make this work, you need to get your API key for Capgo, add it in the secret of your GitHub repository configurer CAPGO_TOKEN.

You pouvez maintenant commiter ces deux fichiers et voir votre premier tag apparaitre dans GitHub!

La mise à jour du commit générera une nouvelle build pour le canal de production.

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

Allez à votre tableau de bord de Capgo et vérifiez votre build qui vient d'apparaître, vous avez maintenant votre système CI/CD.

Si vous voulez que tous vos utilisateurs aient accès à la mise à jour dès qu'elle est disponible, allez à votre canal et définissez-le sur public.

Continuez de l'étape de build automatique et de publication avec Gitlab

Si vous utilisez Automatic build and release with Gitlab pour planifier l'automatisation de CI/CD, connectez-le avec Capgo CI/CD pour le flux de travail produit dans Capgo CI/CD, Capgo Native Builds pour le flux de travail du produit dans Capgo Builds natifs, Capgo Intégrations pour le flux de travail du produit dans Capgo Intégrations, Intégration CI/CD pour le détail d'implémentation dans Intégration CI/CD, et GitHub Intégration d'Actions pour le détail d'implémentation dans GitHub Intégration d'Actions.