Zum Hauptinhalt springen
CI/CD

Entwicklungs- und Produktionsbuild mit GitHub-Aktionen verwalten

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

Artikelcredits

Martin Donadieu

Schreiber

Valeria

Rezensent

Jordan

Redakteur

Entwicklungs- und Produktionsbuild mit GitHub-Aktionen verwalten

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

Einleitung

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

Commit-Konvention

Beginnen Sie zunächst damit, die Commit-Konvention zu befolgen Kontext: Seite/Bereich: Capgo Builder / native cloud build Produktseite. Rolle: Kurzbeschrifteter Navigationspunkt oder -item. Nachrichten-Schlüssel `native_build_builder_credit_first` (Native Build Builder Credit First).Konventionelle Commits

` dies wird Ihnen helfen, die Werkzeuge zu verstehen, wie sie die Versionsnummer aufschlüsseln können, es dauert 5 Minuten, es zu lernen.

GitHub actions for tag

GitHub-Aktionen für die Versionsnummer

Erstellen Sie dann Ihre erste __CAPGO_KEEP_0__-Aktion, um automatisch zu bauen und Tags 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 deinem Hauptzweig eine Versionsnummer freigeben. Und eine alpha Versionsnummer für development, und zuletzt eine Versionshistorie für jeden Commit in CHANGELOG.md.

Keine Sorge, wenn du dieses File nicht hast, es wird für dich erstellt.

Um dies zu ermöglichen, musst du ein PERSONAL ACCESS TOKEN und es in deine GitHub Geheimnisse als PERSONAL_ACCESS_TOKEN.

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

Wenn du das Token erstellst, wähl bitte die 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 danach 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 er 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 Action.

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 diese beiden Dateien committen und sehen Sie Ihre erste Version in Capgo!

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.

Geht 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 Actions fort.

If Sie __CAPGO_KEEP_0__ verwenden Entwicklungs- und Produktionsbuilds mit GitHub-Aktionen verwalten um Kanalrouting und rollierende Veröffentlichung zu planen, verbinden Sie es mit Kanäle Kanäle Kanäle Kanäle Testlösung um das Produktworkflow in der Testlösung und Zielsystem für Versionen Zielsystem für Versionen Zielsystem für Versionen Für das Produktworkflow in der Versionziel-Lösung.

Live-Updates für Capacitor-Apps

Wenn ein Web-Schicht-Bug live ist, versenden 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-Verfahren bleiben.

Menschliche Unterstützung von Martin

Los geht's jetzt

Neueste Nachrichten aus unserem Blog

Capgo gibt Ihnen die besten Einblicke, die Sie benötigen, um ein wirklich professionelles Mobiltelefon-App zu erstellen.