Automatischer Build und Release 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 bei Capgo hinzugefügt haben, diese Anleitung konzentriert sich nur auf die Upload-Phase

Commit-Konvention

Zuerst müssen Sie die Commit-Konvention befolgen Konventionelle Commits` dies wird Ihnen helfen, die Werkzeuge zu verstehen, wie sie die Versionsnummer aufschlüsseln können, es dauert nur 5 Minuten, es zu lernen.

GitLab CI für Tags

Dann müssen Sie Ihre erste GitLab erstellen, um automatisch zu bauen und Tags 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 für jeden Commit in Ihrer Hauptbranch eine Version freigeben. Und ein Changelog-Eintrag für jeden Commit in der Hauptbranch hinzufügen. CHANGELOG.md.

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

Um dies zu ermöglichen, müssen Sie ein __CAPGO_KEEP_0__ in Ihren GitLab CI/CD Variablen einfügen als PERSONAL_ACCESS_TOKEN.

Dies ist erforderlich, damit der CI den Changelog eintragen kann.

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

Zum Schluss müssen Sie das File .cz.toml an der Wurzel Ihres Repository erstellen.

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

Dies ist nur notwendig bei der ersten Anwendung, dann werden die Werkzeuge es selbstständig aktualisieren.

Sie können diese beiden Dateien jetzt 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

Dies wird Ihre Abhängigkeit installieren und vorher bauen, bevor sie an Capgo gesendet wird.

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

Damit dies funktioniert, benötigen Sie Ihren API-Schlüssel für Capgo, fügen Sie ihn in das Geheimnis Ihres GitHub-Repositories ein as CAPGO_TOKEN.

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

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

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

Geht zu Ihrem Capgo-Dashboard und überprüfen Sie 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.

Weiter mit der automatischen Build- und Release-Verarbeitung mit Gitlab

Wenn Sie Automatische Build- und Release-Verarbeitung mit Gitlab für die Planung der CI/CD-Automatisierung verwenden, verbinden Sie sie mit Capgo CI/CD für den Produktionsworkflow in Capgo CI/CD, Capgo Native Builds für das Produktworkflow in Capgo Native Builds Capgo Integrations für das 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.