Passer au contenu principal
CI/CD

Application de build et de mise en production automatique avec Github actions

Créez votre propre pipeline CI/CD avec Github actions gratuitement, déployez votre application Ionic Capacitor JS à chaque fois que vous poussez vers la branche principale.

Martin Donadieu

Martin Donadieu

Responsable de contenu

Application de build et de mise en production automatique avec Github actions

Cette étape se concentre sur l'hébergement GitHub, mais vous pouvez l'adapter avec quelques ajustements pour n'importe quel autre plateforme CI/CD.

Avant-propos

Assurez-vous d'avoir ajouté votre application Capacitor à Capgo en premier lieu, cette étape se concentre uniquement sur la phase de téléchargement. Si vous devez ajouter votre application à Capgo, vous pouvez suivre ce Guide de tutoriel

Convention de commit

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

Commits conventionnels

GitHub actions pour tag

Ensuite, vous devez créer votre première action GitHub pour construire automatiquement et créer 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

Cela publiera un tag pour chaque commit dans votre branch principale. Et ajoutera une entrée de changelog pour chaque commit dans la branch principale dans CHANGELOG.md.

N'ayez pas peur si vous n'avez pas ce fichier, il sera créé pour vous.

Pour que cela fonctionne, créez un TOKEN D'ACCÈS PERSONNEL ajoutez-le à vos GitHub secrets car PERSONAL_ACCESS_TOKEN.

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

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

Enfin, définissez la version dans votre package.json fichier, synchronisez-le avec votre numéro de version Native qui facilitera, puis la prochaine étape.

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

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

Les versions natives et web auront le numéro de version incrémenté après chaque commit.

GitHub actions de construction

Créez un fichier à cet emplacement : .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 le secret de votre __CAPGO_KEEP_0__ repository

To make this work, you need to get your API key for Capgo, add it in the Vous pouvez maintenant commiter ces deux fichiers et voir votre premier tag apparaitre dans GitHub ! L'ajout du commit générera une nouvelle construction pour le canal de production. CAPGO_TOKEN.

GitHub

__CAPGO_KEEP_1__

You devez ajouter votre test 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 souhaitez que tous vos utilisateurs reçoivent la mise à jour dès qu'elle est disponible, allez à votre canal et définissez-le sur public.

Vous pouvez également ajouter la build native de votre application Ionic Capacitor JavaScript en suivant ce tutoriel 👇

Continuez de l'étape de build automatique et de libération de l'application avec les actions de Github

Si vous utilisez Build et libération automatique de l'application avec les actions de Github pour planifier l'automatisation CI/CD, connectez-le 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, Intégrations Capgo pour le flux de travail du produit dans Intégrations Capgo, Intégration CI/CD pour le détail d'implémentation dans Intégration CI/CD, et Intégration d'actions GitHub pour le détail d'implémentation dans Intégration d'actions GitHub.

Mises à jour en direct pour les applications Capacitor

Lorsqu'un bug de couche web est en direct, expédiez la correction par le biais de Capgo au lieu d'attendre des jours pour l'approbation de la boutique d'applications. Les utilisateurs reçoivent la mise à jour en arrière-plan tandis que les modifications natives restent dans le chemin de revue normal.

Commencez maintenant

Dernières actualités de notre Blog

Capgo vous donne les meilleures informations dont vous avez besoin pour créer une application mobile véritablement professionnelle.