Zum Hauptinhalt springen
CI/CD

Manage development and production build with GitHub actions

Verwenden Sie Capgo zum Freigeben Ihres Dev-Builds auf eine bestimmte Kanal und lassen Sie Ihr Team Ihren Capacitor Ionic-App testen, ohne auf Apple- und Google-Überprüfungen warten.

Artikelcredits

Martin Donadieu

Beitragsautor

Valeria

Rezensent

Jordan

Redakteur

Manage development and production build with GitHub actions

Dieses Tutorial konzentriert sich auf die GitHub-Hosting, aber Sie können es mit einem kleinen Anpassung an jede andere CI/CD-Plattform anpassen.

Einleitung

Stellen Sie sicher, dass Sie Ihr Capacitor-Anwendung zuerst in Capgo hinzugefügt haben, da diese Anleitung sich nur auf die Upload-Phase konzentriert.

Einzugsregel

Beginnen Sie zunächst damit, die Einzugsregel zu befolgen konventionelle Commits`Das wird helfen, dass die Werkzeuge verstehen, wie die Versionsnummer aufzubauen ist, es dauert 5 Minuten, es zu lernen.`

Konventionelle Commits

GitHub actions for tag

Dann müssen Sie Ihren ersten GitHub-Aktion erstellen, um automatisch zu bauen und Tags zu erstellen.

Erstellen Sie ein Datei an diesem Pfad: .github/workflows/bump_version.yml

mit diesem Inhalt:

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

Dies wird für jeden Commit in Ihrer Hauptzweig eine Versionsnummer freigeben. Und eine alpha Freigabe für development, und zuletzt eine Änderungsprotokoll-Eintrag für jeden Commit in CHANGELOG.md.

Machen Sie sich keine Sorgen, wenn Sie diese Datei nicht haben, sie wird für Sie erstellt.

Um dies zu ermöglichen, müssen Sie ein Persönlicher Zugriffstoken und fügen Sie es Ihrem GitHub Geheimnisse As PERSONAL_ACCESS_TOKEN.

Dies ist erforderlich, damit der CI die Änderungsprotokoll und die Versionsnummerierung committet.

Wenn Sie den Token erstellen, wählen Sie die Ablaufzeit als never und den Umfang als repo.

Legen Sie die version Schlüssel in Ihrem package.json Datei. Verwenden Sie dafür die letzte Version, die im Store veröffentlicht wurde.

Dies ist nur erforderlich, wenn Sie dies zum ersten Mal tun, dann werden die Werkzeuge es fortan aktualisieren.

Sie können jetzt diese beiden Dateien committen und sehen, wie Ihr erstes Tag in GitHub erscheint!

capacitor-standard-version ist das Paket, das die Magie bewirkt, standardmäßig aktualisiert auch Ihre Versionsnummer in Android und IOS

GitHub-Aktionen für die Build

Erstellen Sie eine Datei an diesem Pfad: .github/workflows/build.yml

mit diesem Inhalt:

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

Dies wird Ihre Abhängigkeit installieren und bauen, bevor sie an Capgo gesendet wird.

Wenn Ihr Befehl für das Bauen anders ist, können Sie ihn im Schritt ändern. build_code step.

Wenn Sie eine Umgebungsvariable benötigen, verwenden Sie das MY_ENV_VAR als secret in Ihrem GitHub Projekt, dann geheim, dann GitHub-Action.

Um Capgo hochzuladen zu können, benötigen Sie Ihren API-Schlüssel für Capgo, fügen Sie ihn in der Geheimnis deines GitHub-Repositories as CAPGO_TOKEN.

You can now commit this both files and see your first version appear in Capgo!

Fügen Sie den Commit hinzu, um eine neue Capacitor-Build für die Produktions- und Entwicklungskanäle zu generieren.

Fügen Sie Ihren Test in der Ionic-Build-Schritt hinzu, um sicherzustellen, dass Ihr code funktioniert.

Gehe zu Ihrem Capgo-Dashboard und überprüfe Ihren Build, der gerade erschienen ist, jetzt haben Sie Ihr CI/CD-System.

Fortsetzen Sie mit der Verwaltung von Entwicklung- und Produktionsbuilds mit GitHub-Aktionen.

Wenn Sie verwenden Die Verwaltung von Entwicklung- und Produktionsbuilds mit GitHub-Aktionen um Kanalrouting und Staged-Rollout zu planen, verbinden Sie es mit Kanälen für die Implementierungsdetails in Kanälen, Kanälen für die Implementierungsdetails in Kanälen, Kanälen für die Implementierungsdetails in Kanälen, Testlösung für Beta für den Produktworkflow in Testlösung für Beta und Zielsystem für Versionen für den Produktworkflow in Zielsystem für Versionen.

Live-Updates für Capacitor-Apps

Bei einem lebenden Web-Schicht-Bug schicken Sie die Reparatur über Capgo anstatt Tage zu warten, bis die App-Store-Zulassung genehmigt ist. Die Benutzer erhalten die Aktualisierung im Hintergrund, während native Änderungen im normalen Review-Prozess bleiben.

Menschliche Unterstützung von Martin

Los geht's jetzt

Neueste von unserem Blog

Capgo gibt Ihnen die besten Einblicke, die Sie benötigen, um eine wirklich professionelle mobile App zu erstellen.