Construction automatique et publication avec Gitlab

Cet tutoriel se concentre sur le CI GitLab, mais vous pouvez l'adapter avec une petite modification à tout autre plateforme CI/CD.

Avant-propos

Assurez-vous d'avoir ajouté votre application en premier lieu à 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 mettre à jour le numéro de version, ce sera de 5 minutes à l'apprendre.

GitLab CI pour tag

Ensuite, vous devez créer votre premier GitLab pour construire automatiquement et créer une étiquette.

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

Cela libellera une étiquette pour chaque commit dans votre branché principal. Et ajoutera une entrée de changelog pour chaque commit dans la branché principale dans CHANGELOG.md.

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

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

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

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

Enfin, pour permettre à l'outil de comprendre où votre version est sauvegardée, vous devez créer le fichier .cz.toml au cœur de votre dépôt.

Et ajoutez cela à 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 comme celle que vous avez dans votre package.json fichier.

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

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

GitHub actions de 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 installe et construit 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 step.

Pour que cela fonctionne, vous devez obtenir votre clé API pour Capgo, puis l'ajouter dans le secret de votre GitHub repository comme CAPGO_TOKEN.

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

L'ajout du commit générera un nouveau 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 Capgo dashboard et vérifiez votre build qui vient d'apparaitre, vous avez maintenant votre système CI/CD.

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

Continuez de Automatic build and release with Gitlab

Si vous utilisez Construction automatique et déploiement avec Gitlab pour planifier l'automatisation de CI/CD, connectez-l’avec Capgo CI/CD pour le flux de travail du produit dans Capgo CI/CD Capgo Builds natifs 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 les détails d'implémentation dans l'intégration CI/CD, et GitHub Actions Integration pour les détails d'implémentation dans GitHub Intégration d'Actions.