Semantic Releases mit GitHub Actions

Durch den Einsatz von Conventional Commits und Semantic Versioning lässt sich einfach ein automatischer Releaseprozess für Software Projekte umsetzen. Mit GitHub Actions kann der gesamte Prozess zur Versionsermittlung und Veröffentlichung serverless abgebildet werden und möglichst nah am Quellcode verwalten.

Was ist Semantic Versioning?

Die Diskussionen zu Versionierung und Release sind vermutlich so alt wie die Entwicklung von Software. Viele Projekte nutzen ein eigenes Schema zur Versionsgebung und so werden die üblichen Diskussionen in Entwicklerteams dazu nicht abnehmen. Nutzt man Semantic Versioning als einheitliches Schema, lassen sich dies meist vermeiden.

Das Semantic Versioning basiert auf dem Format MAJOR.MINOR.PATCH und definiert die Elemente wie folgt:

• MAJOR wird erhöht, wann immer breaking changes einführt werden;
• MINOR wird erhöht, wenn abwärtskompatibel neue Funktionalitäten hinzugefügt wurden;
• PATCH wird erhöht, wenn abwärtskompatibel Fehler beseitigt werden.

Was sind Conventional Commits?

Neben der Diskussion zur Versionierung, sehen wir bei Projekten regelmäßig Unterhaltungen zu Format und Inhalt von Commit Messages bei der Entwicklung. Auch hier gibt es seit einiger Zeit ein einheitliches Schema was viele Projekte und Teams verwenden: Convential Commits.

Eine Commit Message nach Convential Commits basiert auf dem Schema <type>[optional scope]: <description>; durch den Einsatz von einheitlichen Werten für type lässt sich ein Rückschluss auf die Art der Änderung bilden:

• fix kennzeichnet eine Fehlerbeseitigung;
• feat beschreibt eine neue Funktionalität;
• Angaben wie build:, chore:, ci:, docs:, style:, refactor:, perf: oder test: kennzeichnen sonstige Änderungen am Quellcode.

Diese Unterteilung ist wichtig um Conventional Commits mit Semantic Versioning zu verknüpfen. Durch eine Automatisierung am Quellcode lässt sich so auf Basis der Commit Messages ermitteln, ob und wie die Version des Projekts erhöht werden muss:

Durch fix: wird eine neue PATCH Version notwendig; ein feat: erfordert eine neue MINOR Version und mit dem Hinweis BREAKING CHANGE wird eine neue MAJOR Version notwendig.

Automatisierung mit GitHub Actions

Werden Conventional Commits für ein Projekt genutzt, lässt sich durch eine Automatisierung am Quellcode ein automatischer Releaseprozess abbilden. Liegt der Quellcode bei GitHub, sind GitHub Actions eine gute Wahl für nahtlose Integrationen.

Durch die folgende Konfigurationsdatei (z.B. version.yml) im Ordner .github/workflows lässt sich bei jedem push in den Branch main die Aktion zum Ermitteln der neuen Version integrieren:

name: Version

on:
  push:
    branches: ["main"]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Semantic Release
        uses: cycjimmy/semantic-release-action@v2
        id: semantic
        with:
          extra_plugins: |
            @semantic-release/git
            @semantic-release/changelog            
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Die GitHub Action cycjimmy/semantic-release-action analysiert nach dem Checkout die vorhanden Commits und berechnet danach die neue Version. Durch die Angabe eines GitHub Tokens kann der Quellcode mit einem entsprechenden git tag versehen werden und ein Release in GitHub erstellt werden. Der NPM_TOKEN kann optional genutzt werden, um ein Paket bei NPM zu veröffentlichen.

Sebastian is a Senior Cloud Consultant at superluminar GmbH, AWS Serverless Hero and AWS Certified Solutions Architect. He writes here in German about AWS, Serverless, Software development, Go, TypeScript and React. English Articles can be found on his Website sbstjn.com and he can be found on Twitter under @sbstjn.