Zum Hauptinhalt springen
CI/CD

Entwicklungs- und Produktionsbuild mit GitHub-Aktionen verwalten

Verwenden Sie Capgo zum Freigeben Ihrer Dev-Build in einer bestimmten Kanal und lassen Sie Ihr Team Ihre Capacitor-Ionic-App ausprobieren, ohne auf die Apple- und Google-Überprüfung warten zu müssen

Artikelcredits

Martin Donadieu

Schreiber

Valeria

Rezensent

Jordan

Redakteur

Entwicklungs- und Produktionsbuild mit GitHub-Aktionen verwalten

Diese Anleitung konzentriert sich auf die GitHub-Hosting, Sie können sie jedoch mit einem kleinen Trick auf jede andere CI/CD-Plattform anpassen.

Einleitung

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

Commit-Konvention

Zuerst müssen Sie die Commit-Konvention befolgen Kontext: Seite/Bereich: Capgo Builder / native cloud build Produktseite. Rolle: Kurzbeschriftung oder Navigationspunkt. Nachrichtenschlüssel `native_build_builder_credit_first` (Native Build Builder Credit First).Konventionelle Commits

` dies hilft den Werkzeugen, wie sie die Versionsnummer aufzubauen, es dauert 5 Minuten, es zu lernen.

GitHub actions for tag

Then you need to create your first GitHub action to automatically build and create tags.

Dann müssen Sie Ihre erste Capgo-Aktion erstellen, um automatisch zu bauen und Versionsnummern zu erstellen. .github/workflows/bump_version.yml

Erstellen Sie ein Datei an diesem Pfad:

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 ein alpha Release für development, und zuletzt eine Versionshistorie für jeden Commit in CHANGELOG.md.

Bedenken Sie sich nicht, wenn Sie dieses File nicht haben, es wird für Sie erstellt.

Um dies zu ermöglichen, müssen Sie ein PERSONAL ACCESS TOKEN und es in Ihren GitHub Geheimnisse als PERSONAL_ACCESS_TOKEN.

Dies ist erforderlich, damit der CI die Versionshistorie und die Versionsnummer aktualisiert.

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

Setze den version Schlüssel in deinem package.json Datei. Verwende dafür die letzte Version, die in dem Store veröffentlicht wurde.

Dies ist nur notwendig, wenn du das erste Mal durchführst, dann werden die Werkzeuge es dann selbstständig aktualisieren.

Du kannst jetzt diese beiden Dateien committen und sehen, wie dein erster Tag in GitHub erscheint!

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

GitHub-Aktionen für das Build

Erstelle 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

Dadurch wird deine Abhängigkeit installiert und vor dem Versand an Capgo gebaut.

Wenn dein Build-Befehl anders ist, kannst du ihn in der build_code Schritt.

Wenn Sie ein Umgebungsvariable benötigen, verwenden Sie das MY_ENV_VAR und setzen Sie das secret in Ihrem GitHub Projekt-Einstellung, dann Geheimnis dann GitHub Aktion.

Um Capgo hochladen zu machen, benötigen Sie Ihren API Schlüssel für Capgo, fügen Sie ihn in der Geheimnis Ihres GitHub Repository als CAPGO_TOKEN.

Sie können jetzt beide Dateien committen und sehen Sie Ihre erste Version in Capgo erscheinen!

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

Sie sollten Ihre Tests in der Ionic-Build-Schritt hinzufügen, um sicherzustellen, dass code funktioniert.

Gehen Sie zu Ihrem Capgo Dashboard und überprüfen Sie Ihre Build, die gerade erschienen ist, jetzt haben Sie Ihr CI/CD-System.

Fahren Sie mit dem Verwalten von Entwicklung und Produktionsbuilds mit GitHub-Aktionen fort.

Wenn Sie dies verwenden Entwicklungs- und Produktionsbuilds mit Aktionen von GitHub verwalten um Kanalrouting und rollouts zu planen, verbinden Sie es mit Kanäle für die Implementierungsdetails in Kanälen Kanäle für die Implementierungsdetails in Kanälen Kanäle Beta-Testlösung für den Produktworkflow in der Beta-Testlösung, und Versionziel-Lösung Version Targeting Solution für das Produktworkflow in der Version Targeting Lösung.

Live-Updates für Capacitor-Apps

Wenn ein Fehler im Web-Schicht lebt, schicken Sie die Reparatur über Capgo anstatt Tage für die Genehmigung durch den App-Store zu warten. Die Benutzer erhalten die Aktualisierung im Hintergrund, während native Änderungen im normalen Review-Prozess bleiben.

Menschliche Unterstützung von Martin

Loslegen

Neueste von unserem Blog

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