kurmann
commented
5 months ago Herzlichen Dank für den Hinweis mit Release Drafter. Ich habe mir das angeschaut und entschieden, dass ich einen Versuch damit starten will.
Und zwar gleich im Projekt "kurmann/GitHub.Workflows" selbst. Dieses Projekt soll nützliche Workflows anbieten für meine Zwecke. Und diese Workflows werden selbst natürlich auch wieder versioniert.
Hier ist die Doku von Release Drafter zur Anwendung. Wie würdest du nun den Release Drafter konfigurieren anhand unserem Gesprächsverlaufs?
name: Release Drafter
on:
push:
# branches to consider in the event; optional, defaults to all
branches:
- master
# pull_request event is required only for autolabeler
pull_request:
# Only following types are handled by the action, but one can default to all as well
types: [opened, reopened, synchronize]
# pull_request_target event is required for autolabeler to support PRs from forks
# pull_request_target:
# types: [opened, reopened, synchronize]
permissions:
contents: read
jobs:
update_release_draft:
permissions:
# write permission is required to create a github release
contents: write
# write permission is required for autolabeler
# otherwise, read permission is required at least
pull-requests: write
runs-on: ubuntu-latest
steps:
# (Optional) GitHub Enterprise requires GHE_HOST variable set
#- name: Set GHE_HOST
# run: |
# echo "GHE_HOST=${GITHUB_SERVER_URL##https:\/\/}" >> $GITHUB_ENV
# Drafts your next Release notes as Pull Requests are merged into "master"
- uses: release-drafter/release-drafter@v5
# (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml
# with:
# config-name: my-config.yml
# disable-autolabeler: true
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Um den Release Drafter effektiv in deinem Projekt "kurmann/GitHub.Workflows" zu integrieren, basierend auf unserem Gesprächsverlauf, sind hier einige Schritte und Konfigurationen, die du vornehmen solltest. Ich werde die Konfiguration so anpassen, dass sie deinen Anforderungen entspricht, einschließlich der Verwendung von Pull Requests zur Generierung von Release Notes.
Schritt 1: Konfiguration des Release Drafter Workflows
Zunächst musst du sicherstellen, dass der Workflow-Trigger richtig gesetzt ist. Du verwendest den main-Branch (statt master), also sollte dies reflektiert werden:
name: Release Drafter
on:
push:
branches:
- main # Achten darauf, dass du "main" verwendest, falls dies dein Hauptbranch ist
pull_request:
types: [opened, reopened, synchronize]
pull_request_target:
types: [opened, reopened, synchronize]
permissions:
contents: read
pull-requests: write
jobs:
update_release_draft:
runs-on: ubuntu-latest
steps:
- uses: release-drafter/release-drafter@v5
with:
# Optional: Pfad zur Konfigurationsdatei anpassen, falls nötig
config-name: 'release-drafter.yml'
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}Schritt 2: Erstellung einer Konfigurationsdatei für Release Drafter
Erstelle eine Datei namens release-drafter.yml im Verzeichnis .github/. Diese Datei wird die Konfigurationen für Release Drafter enthalten. Hier ist ein Beispiel, wie du diese Datei konfigurieren könntest, basierend auf unseren vorherigen Diskussionen über die automatisierte Generierung von Release Notes, die die tatsächlichen Beiträge widerspiegeln:
name-template: 'v$NEXT_PATCH_VERSION'
tag-template: 'v$NEXT_PATCH_VERSION'
categories:
- title: '🚀 Features'
labels:
- 'feature'
- title: '🐛 Bug Fixes'
labels:
- 'bug'
- title: '📝 Documentation'
labels:
- 'documentation'
- title: '🧰 Maintenance'
labels:
- 'maintenance'
change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
template: |
## What's Changed
$CHANGES
version-resolver:
major:
labels:
- 'major'
minor:
labels:
- 'minor'
patch:
labels:
- 'patch'Erläuterung der Konfiguration:
- name-template und tag-template: Diese Vorlagen definieren, wie die Release-Namen und Tags benannt werden.
$NEXT_PATCH_VERSIONwird automatisch durch die nächste Patch-Version ersetzt, basierend auf den Labels, die den Pull Requests zugeordnet sind. - categories: Definiere Kategorien für deine Release Notes. Jede Kategorie kann mit GitHub Labels verknüpft werden. Pull Requests, die mit diesen Labels versehen sind, werden unter der entsprechenden Überschrift in den Release Notes gruppiert.
- change-template: Dieses Template definiert, wie einzelne Änderungen in den Release Notes formatiert werden.
$TITLE,$AUTHORund#$NUMBERwerden durch den Titel des Pull Requests, den Autor und die Nummer des Pull Requests ersetzt. - version-resolver: Legt fest, wie die Versionierung basierend auf den Labels gehandhabt wird. Labels wie 'major', 'minor' und 'patch' bestimmen, ob die nächste Version ein Major-, Minor- oder Patch-Release ist.
Schritt 3: Überprüfung und Test
Nachdem du alles eingerichtet hast, teste den Workflow durch das Mergen eines Pull Requests in deinen main-Branch. Überprüfe, ob der Release Drafter die Release Notes entsprechend deiner Konfiguration aktualisiert.
Durch diese Schritte kannst du sicherstellen, dass deine Releases gut dokumentiert sind und die Release Notes automatisch generiert werden, was dir Zeit spart und den Überblick über die Änderungen in deinem Projekt verbessert.
Vorabdiskussion:
1