Automatische Build- und Releasefunktion mit Gitlab

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

Einleitung

Sicherstellen, dass Sie Ihre App zuerst bei Capgo hinzugefügt haben, da diese Anleitung sich nur auf die Upload-Phase konzentriert.

Commit-Konvention

Beginnen Sie zunächst damit, die Commit-Konvention zu befolgen konventionelle Commits` dies wird Ihnen helfen, die Werkzeuge zu verstehen, wie sie die Versionsnummer aufzubauen, es dauert 5 Minuten, um es zu lernen.

GitLab CI für Tag

Dann müssen Sie Ihren ersten GitLab erstellen, um automatisch zu bauen und eine Versionsnummer zu erstellen.

Erstellen Sie ein Datei an diesem Pfad: .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

Dies wird eine Versionsnummer für jeden Commit in Ihrer Hauptzweig erstellen. Und eine Änderungsprotokoll-Eintrag für jeden Commit in der Hauptzweig in CHANGELOG.md.

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

Um dies zu ermöglichen, erstellen Sie ein Persönlicher Zugriffstoken und fügen Sie es Ihren GitLab CI/CD Variablen als PERSONAL_ACCESS_TOKEN.

Dies ist erforderlich, damit der CI die Änderungsliste einreichen kann.

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

Zum Schluss, um dem Tool zu ermöglichen, wo Ihre Version gespeichert ist, müssen Sie die Datei .cz.toml am Wurzelort Ihres Repositoriums.

Und fügen Sie dies hinein :

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$major.$minor.$patch$prerelease"
version = "0.11.5"
version_files = [
    "package.json:version",
    ".cz.toml"
]

Setzen Sie die Version in diesem Datei gleich der, die Sie in Ihrem package.json Datei.

Dies ist nur notwendig zum ersten Mal, dann werden die Werkzeuge es auf dem Laufenden halten.

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

GitHub Aktionen für die Erstellung

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 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

Das 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 step.

Um dies zu ermöglichen, benötigen Sie Ihren API-Schlüssel für Capgo, fügen Sie ihn in der Geheimnis Ihres GitHub-Repositorys als CAPGO_TOKEN.

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

Die Commits werden eine neue Build für den Produktionskanal generieren.

Sie sollten Ihre Tests in der Build-Schritt hinzufügen, um sicherzustellen, dass Ihr 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.

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.

Fortsetzen Sie von Automatic build and release with Gitlab

Wenn Sie GitLab verwenden um CI/CD-Automatisierung zu planen, verbinden Sie es mit Automatic build and release with Gitlab Capgo CI/CD zur Produktworkflow in Capgo CI/CD Capgo Native Builds zur Produktworkflow in Capgo Native Builds Capgo Integrations zur Produktworkflow in Capgo Integrations CI/CD-Integration zur Implementierungsdetail in CI/CD-Integration, und GitHub Actions-Integration zur Implementierungsdetail in GitHub Actions-Integration