Build e release automatiche con Gitlab

Questo tutorial si concentra su GitLab CI, ma puoi adattarlo con qualche piccola modifica a qualsiasi altra piattaforma CI/CD.

Prefazione

Assicurati di aver prima aggiunto la tua app a Capgo, questo tutorial si focalizza solo sulla fase di upload

Convenzione dei commit

Per prima cosa, devi iniziare a seguire la convenzione dei commit conventional commits` questo aiuterà il tooling a capire come incrementare il numero di versione; bastano 5 minuti per impararlo.

GitLab CI per il tag

Poi devi creare il tuo primo GitLab per fare la build e creare il tag automaticamente.

Crea un file in questo percorso: .github/workflows/bump_version.yml

con questo contenuto:

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

Questo rilascerà un tag per ogni commit nel branch main. E aggiungerà una voce di changelog per ogni commit nel branch main in CHANGELOG.md.

Non preoccuparti se non hai questo file: verrà creato per te.

Per farlo funzionare, crea un PERSONAL ACCESS TOKEN e aggiungilo alle variabili GitLab CI/CD come PERSONAL_ACCESS_TOKEN.

Questo serve per permettere alla CI di fare il commit del changelog.

Quando crei il token, imposta l'espiraizone su never e lo scope su repo.

Infine, per permettere allo strumento di capire dove è salvata la versione, devi creare il file .cz.toml nella root del tuo repository.

E inserisci questo all'interno:

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

Imposta la versione in questo file uguale a quella presente nel tuo package.json file.

È necessario solo la prima volta, poi gli strumenti lo terranno aggiornato.

Ora puoi fare il commit di entrambi i file e vedere comparire il tuo primo tag in GitHub!

Azioni GitHub per la build

Crea un file in questo percorso: .github/workflows/build.yml

con questo contenuto:

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

Questo installerà e farà la build delle tue dipendenze prima di inviarle a Capgo.

Se il tuo comando di build è diverso, puoi modificarlo nel build_code passo.

Per farlo funzionare, devi ottenere la tua chiave API per Capgo e aggiungerla nei secret del tuo repository GitHub come CAPGO_TOKEN.

Ora puoi fare il commit di entrambi i file e vedere comparire il tuo primo tag in GitHub!

Aggiungendo il commit, verrà generata una nuova build per il canale di produzione.

Dovresti aggiungere i test nella fase di build per assicurarti che il tuo code funzioni correttamente.

Vai alla dashboard di Capgo e controlla la build appena apparsa: ora hai il tuo sistema CI/CD.

Se vuoi che tutti i tuoi utenti ricevano l'aggiornamento non appena è disponibile, vai nel tuo canale e impostalo su public.

Continua da Automatic build and release with Gitlab

Se stai usando Build e release automatiche con Gitlab per pianificare l'automazione CI/CD e connetterla a CI/CD con Capgo per il workflow del prodotto in Capgo CI/CD, Capgo Native Build per il workflow di prodotto in Capgo Native Builds, Integrazioni Capgo per il workflow di prodotto in Integrazioni Capgo, Integrazione CI/CD per i dettagli implementativi in CI/CD Integration, e Integrazione GitHub Actions per i dettagli implementativi in GitHub Actions Integration.