Automatischer Build und Release-App mit Github Aktionen

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

Vorwort

Stellen Sie sicher, dass Sie Ihre Capacitor-App zuerst in Capgo hinzugefügt haben, diese Anleitung konzentriert sich nur auf die Upload-Phase. Wenn Sie Ihre App in Capgo hinzufügen müssen, können Sie diese Anleitung befolgen Anleitung

Commitkonvention

Zuerst müssen Sie mit der Commitkonvention beginnen konventionelle Commits` dies wird den Werkzeugen helfen, wie sie die Versionsnummer aufschlüsseln sollen, es dauert 5 Minuten, es zu lernen.

GitHub Aktionen für die Etikettierung

Dann müssen Sie Ihre erste GitHub Aktion erstellen, um automatisch zu bauen und eine Etikettierung zu erstellen.

Erstellen Sie ein File an dieser Stelle: .github/workflows/bump_version.yml

mit diesem Inhalt:

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

Das wird für jeden Commit in Ihrer Hauptbranch eine Etikettierung erstellen. Und eine Änderungsliste-Eintrag für jeden Commit in der Hauptbranch in CHANGELOG.md.

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

Um dies zu machen, erstellen Sie ein PERSONAL ACCESS TOKEN und füge es deinem GitHub hinzu Geheimnisse als PERSONAL_ACCESS_TOKEN.

Dies ist notwendig, damit der CI die Änderungsprotokoll einreichen kann.

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

Zuletzt setzen Sie die Version in Ihrem package.json Datei, synchronisieren Sie sie mit Ihrer Native Version, die es erleichtern wird, dann folge dem nächsten Schritt.

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

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

Beide native und Web-Plattformen werden die Versionsnummer nach jedem Commit erhöhen.

GitHub-Aktionen für die Erstellung

Erstellen Sie ein 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 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

Dies wird Ihre Abhängigkeit installieren und vor der Übermittlung an Capgo bauen.

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

Damit dies funktioniert, müssen Sie Ihren API-Schlüssel für Capgo erhalten, ihn in der Geheimzahl Ihres GitHub-Repositorys hinzufügen als CAPGO_TOKEN.

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

Der Commit wird eine neue Build für den Produktionskanal generieren.

You sollten Ihre Test in der Build-Schritt hinzufügen, um sicherzustellen, dass Ihre code funktioniert.

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

Wenn Sie möchten, dass alle Ihre Benutzer die Aktualisierung erhalten, sobald sie verfügbar ist, gehen Sie zu Ihrem Kanal und setzen Sie ihn auf public.

Sie können auch den nativen Build Ihrer Ionic Capacitor JavaScript-Anwendung hinzufügen, indem Sie diesem Tutorial folgen 👇

Fortsetzen Sie von Automatic build and release app with Github actions

Wenn Sie CI/CD-Automatisierung mit "Automatic build and release app with __CAPGO_KEEP_0__ actions" planen, verbinden Sie es mit Github CI/CD __CAPGO_KEEP_0__ CI/CD für den Produktworkflow in __CAPGO_KEEP_0__ CI/CD, Capgo Native Builds Capgo Native Builds für den Produktworkflow in Capgo Native Builds, Wenn Sie Capgo verwenden Automatic build and release app with Capgo actions Capgo Integrations für den Produktworkflow in Capgo Integrations, CI/CD-Integration für die Implementierungsdetails in CI/CD-Integration, und GitHub Actions-Integration für die Implementierungsdetails in GitHub Actions-Integration.