Automatische Build- und Releasefunktion mit Gitlab

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

Vorwort

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

Commit-Konvention

Zuerst müssen Sie der Commit-Konvention folgen Konventionelle Commits` dies wird den Werkzeugen helfen, wie sie die Versionsnummer aufschlüsseln sollen, es dauert nur 5 Minuten, es zu lernen.

GitLab CI für Tag

Erstelle dann deine erste GitLab, um automatisch zu bauen und einen Tag zu erstellen.

Erstelle 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

Das wird einen Tag für jeden Commit in deiner Hauptbranch erstellen. Und eine Änderungsprotokoll-Einträge für jeden Commit in der Hauptbranch hinzufügen in CHANGELOG.md.

Bekümmere dich nicht, wenn du diese Datei nicht hast, sie wird für dich erstellt.

Um dies zu machen, erstelle ein __CAPGO_KEEP_0__ und füge es zu deinen GitLab CI/CD Variablen als PERSONAL_ACCESS_TOKEN.

Dies ist notwendig, um dem CI den Änderungsprotokoll-Einträge zu ermöglichen.

Wenn du den Token erstellst, wähle die Ablaufzeit als never und den Umfang als repo.

Zuletzt müssen Sie das Tool dazu bringen, wo Ihre Version gespeichert ist, indem Sie das Datei erstellen. .cz.toml am Wurzelort Ihres Repositories.

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 dieser Datei auf die gleiche, die Sie in Ihrem package.json Datei haben.

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 das 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 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 dem Senden an Capgo bauen.

Wenn Ihr Build-Befehl anders ist, können Sie ihn in der build_code Schritt.

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

Gehe zu Ihrem Capgo-Dashboard und überprüfe 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.

Weiter mit Automatischer Build und Release mit Gitlab

Wenn Sie Automatischer Build und Release mit Gitlab für die Automatisierung von CI/CD zu planen, mit ihm verbunden Capgo CI/CD für den Produktworkflow in Capgo CI/CD Capgo Native Builds für den Produktworkflow in Capgo Native Builds Capgo Integrations für den Produktworkflow in Capgo Integrations CI/CD-Integration für die Implementierungsdetails in CI/CD-Integration GitHub Actions-Integration für die Implementierungsdetails in GitHub Actions-Integration