Automatisches Build und Release mit GitLab

Dieses Tutorial konzentriert sich auf GitLab CI, lässt sich aber mit wenigen Anpassungen auf jede andere CI/CD-Plattform übertragen.

Vorwort

Stelle sicher, dass du deine App zuerst in Capgo hinzugefügt hast; dieses Tutorial konzentriert sich nur auf die Upload-Phase.

Commit-Konvention

Zuerst musst du mit der Commit-Konvention beginnen Conventional Commits` – das hilft den Tools, die Versionsnummer korrekt zu aktualisieren. Das Lernen dauert nur 5 Min.

GitLab CI für Tags

Erstelle dann deinen ersten GitLab-Token, um automatische Builds und Tags zu ermöglichen.

Erstelle eine Datei unter 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

Dadurch wird für jeden Commit im main-Branch ein Tag veröffentlicht und ein Eintrag im Changelog erstellt. CHANGELOG.md.

Keine Sorge, falls die Datei fehlt – sie wird automatisch für dich erstellt.

Um das einzurichten, erstelle einen PERSONAL ACCESS TOKEN und füge es als GitLab CI/CD-Variable hinzu: PERSONAL_ACCESS_TOKEN.

Dies ist erforderlich, damit die CI das Changelog committen kann.

Wähle beim Erstellen des Tokens als Ablaufdatum never und als Scope repo.

Schließlich müssen Sie die Datei erstellen, damit das Tool weiß, wo Ihre Version gespeichert ist .cz.toml im Root-Verzeichnis deines Repositories erstellen.

Und füge dies hier ein:

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

Setze die Version in dieser Datei auf denselben Wert wie in deiner package.json Datei.

Dies ist nur beim ersten Mal nötig; danach hält das Tool sie automatisch aktuell.

Du kannst nun beide Dateien committen und siehst deinen ersten Tag in GitHub!

GitHub Actions für den Build

Erstelle eine Datei unter 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

Dadurch wird deine Dependency installiert und gebaut, bevor sie an Capgo gesendet wird.

Falls dein Build-Befehl anders lautet, kannst du ihn hier ändern: build_code Schritt.

Damit das funktioniert, benötigst du deinen API Key für Capgo. Füge ihn in das Secret deines GitHub Repositories hinzu als CAPGO_TOKEN.

Du kannst nun beide Dateien committen und siehst deinen ersten Tag in GitHub!

Ein Commit löst einen neuen Build für den Production-Channel aus.

Du solltest Tests im Build-Schritt hinzufügen, um sicherzustellen, dass dein code korrekt funktioniert.

Gehe zu deinem Capgo Dashboard und überprüfe deinen soeben erstellten Build – dein CI/CD-System steht nun bereit.

Wenn alle deine Nutzer das Update erhalten sollen, sobald es verfügbar ist, geh zu deinem Channel und stelle ihn auf public.

Weiter mit: Automatisches Build und Release mit GitLab

Wenn du es nutzt Automatisches Build und Release mit GitLab um CI/CD-Automatisierung zu planen, verbinde es mit Capgo CI/CD für den Produkt-Workflow in Capgo CI/CD, Capgo Native Builds optimieren für den Produkt-Workflow in Capgo Native Builds, Capgo Integrationen für den Produkt-Workflow in Capgo Integrations, CI/CD-Integration für die Implementierungsdetails in der CI/CD-Integration und GitHub Actions-Integration für die Implementierungsdetails in der GitHub Actions-Integration.