Plugin-Überblick

semrel Plugin-Ökosystem: Provider, Conditions, Analyzer, Generatoren, Updater, Packager, Publisher und Hooks, verbunden mit der Kern-Release-Pipeline

Die Release-Pipeline von semrel besteht aus eigenständigen Plugin-Binärdateien. Jedes Plugin wird lokal gefunden und als Subprozess ausgeführt – es gibt keine gRPC-Schicht und keinen RPC-Handshake.

So funktionieren Plugins

semrel liest jeden Plugin-Eintrag aus .semrel.yaml.
Der Wert uses: wird zu einer Binärdatei namens semrel-plugin-<name> aufgelöst, nachdem semrel Namespace, Version oder Kategorie-Präfix entfernt hat.
semrel sucht diese Binärdatei zuerst an einem expliziten path:, dann in .semrel/plugins/, dann in ~/.semrel/plugins/, dann in $PATH.
Plugin-args:-Werte werden als Umgebungsvariablen im Format SEMREL_PLUGIN_<KEY>=<value> bereitgestellt.
Der Release-Kontext wird ebenfalls über Umgebungsvariablen übergeben, sodass jedes Plugin dieselbe Version, Branch, Tag, denselben Changelog und denselben Dry-Run-Status lesen kann.
semrel führt die Binärdatei aus und verwendet das Prozessergebnis, um die Pipeline fortzusetzen oder zu stoppen.

Release-Kontext-Umgebung

Diese Umgebungsvariablen stehen Plugin-Prozessen während der Ausführung zur Verfügung.

Variable	Beschreibung
`SEMREL_VERSION`	Aufgelöste Release-Version für den aktuellen Lauf
`SEMREL_TAG_NAME`	Vollständiger Tag-Name für die Release
`SEMREL_CURRENT_VERSION`	Aktuelle Projektversion
`SEMREL_NEXT_VERSION`	Nächste für die Release ausgewählte Version
`SEMREL_BUMP`	Berechnete Bump-Stufe
`SEMREL_BRANCH`	Aktuelle Git-Branch
`SEMREL_TAG_PREFIX`	Konfiguriertes Tag-Präfix
`SEMREL_CHANGELOG`	Erzeugter Changelog-Inhalt
`SEMREL_DRY_RUN`	Ob der aktuelle Lauf ein Dry-Run ist

Plugin-Typen

Der aktuelle offizielle Plugin-Katalog ist in acht Kategorien organisiert.

Provider Plugin

Kümmert sich um Forge- und Git-Operationen wie das Lesen der Release-Historie, das Erstellen von Tags und das Veröffentlichen von Releases.

Condition Plugin

Prüft, ob die aktuelle Umgebung eine Release veröffentlichen darf.

Analyzer Plugin

Untersucht Commits und entscheidet über die SemVer-Bump-Stufe.

Generator Plugin

Erzeugt Changelogs, Release Notes und andere auf Releases bezogene Inhalte.

Updater Plugin

Aktualisiert versionierte Projektdateien, bevor die Release abgeschlossen wird.

Packager Plugin

Erstellt distributierbare Artefakte wie Linux-Pakete aus vorbereiteten Release-Eingaben.

Publisher Plugin

Veröffentlicht Docker-Images oder Release-Artefakte in Registries und über HTTP-Endpunkte.

Hook Plugin

Sendet Benachrichtigungen oder führt nach Erfolg oder Fehler nachgelagerte Automatisierung aus.

Was ist mit Go-Binaries, Docker/Podman-Images, Helm und ähnlichen Zielen?

Diese Ziele sind heute über ein geteiltes Modell abgedeckt: Updater bereiten versionierte Projektmetadaten vor, während Packaging und Publishing über dedizierte Plugins und CI-Jobs laufen.

Ziel	Aktuelle Plugins	Was sie heute tun	Typischer nächster Schritt
Go-Binaries	`updater-go`	Aktualisiert Go-Versionsvariablen vor dem Release-Tagging.	Binaries in CI mit `go build` bauen und danach Artefakte paketieren/veröffentlichen.
Docker-Images	`updater-docker`, `publisher-docker`	Aktualisiert Versionsargumente in Dockerfiles; pusht ein Image, das bereits im Docker-Daemon vorhanden ist.	Vor dem Publisher in CI bauen und authentifizieren.
Podman-Images	`updater-docker`	Aktualisiert Versionsargumente in Dockerfiles.	Mit Podman in CI bauen und veröffentlichen; `publisher-docker` setzt ausdrücklich den Docker-CLI-Vertrag voraus.
Helm-Charts	`updater-helm`	Aktualisiert `Chart.yaml`-Version und optional `appVersion`.	Charts in CI oder OCI-kompatiblen Registries paketieren und veröffentlichen.
Linux-Pakete	`packager-nfpm`	Baut `deb`-, `rpm`- und `apk`-Pakete über `nfpm`.	Erzeugte Pakete in deine Paketkanäle veröffentlichen.
Generische/OCI-Artefakte	`publisher-generic-http`, `publisher-oci`	Lädt Release-Artefakte zu HTTP-Endpunkten oder OCI-Registries hoch.	Publisher nach Build-/Package-Stufen in die Pipeline einhängen.

Plugin-Erkennung

Entdecke offizielle Plugins im Plugin Registry, installiere sie mit semrel plugin install <ref> und nutze die Anleitung Plugins verwalten für Lock-Dateien und Restore-Workflows.

semrel löst Plugins aus dem konfigurierten uses:-Wert auf:

plugins:
  - uses: @semrel/provider-github
    name: github-release
    args:
      owner: MyOrg
      repo: my-repo

  - uses: slack-notify
    path: /usr/local/bin/semrel-plugin-slack
    args:
      webhook_url: ${{ env.SLACK_WEBHOOK }}

Plugin-Lebenszyklus

Nächste Schritte

Offizielle Plugins Plugins verwalten Plugin-Registry Migrationsanleitung Plugin entwickeln