Informationen zu automatisch generierten Versionshinweisen
Automatisch generierte Versionshinweise bieten eine automatisierte Alternative zum manuellen Schreiben von Versionshinweisen für deine GitHub-Releases. Mit automatisch generierten Versionshinweisen kannst du schnell einen Überblick über den Inhalt einer Version erstellen. Automatisch generierte Versionshinweise umfassen eine Liste der zusammengeführten Pull Requests, eine Liste der Mitwirkenden an der Version und einen Link zu einem vollständigen Änderungsprotokoll.
Du kannst auch deine automatisierten Versionshinweise anpassen, indem du Beschriftungen verwendest, um benutzerdefinierte Kategorien zu erstellen, um Pull Requests zu strukturieren, die du einschließen möchtest, und um bestimmte Bezeichnungen und Benutzer*innen aus der Ausgabe auszuschließen.
Erstellen von automatisch generierten Versionshinweisen für ein neues Release
-
Navigieren Sie auf GitHub zur Hauptseite des Repositorys.
-
Klicke rechts neben der Liste der Dateien auf Releases.
-
Klicke auf oben auf der Seite auf Neues Release entwerfen.
-
Wähle im Dropdownmenü Tag auswählen ein Tag für das Release aus.
- Um ein vorhandenes Tag zu verwenden, klicke auf das Tag.
- Gib zum Erstellen eines neuen Tags eine Versionsnummer für dein Release ein, und klicke dann auf Neues Tag erstellen.
-
Wenn du ein neues Tag erstellt hast, verwende das Dropdownmenü Ziel, und klicke dann auf den Branch, der das zu veröffentlichende Projekt enthält.
-
Optional kannst du über dem Beschreibungsfeld das Dropdownmenü Vorheriges Tag auswählen und dann auf das Tag klicken, das die vorherige Version kennzeichnet.
-
Gib im Feld „Releasetitel“ einen Titel für dein Release ein.
-
Klicken Sie oberhalb des Beschreibungsfeldes auf Versionshinweise generieren.
-
Überprüfe die generierten Notizen, um sicherzustellen, dass sie alle (und nur) die Informationen enthalten, die du einschließen möchtest.
-
Um optional binäre Dateien wie kompilierte Programme in deinen Release einzubinden, ziehe die Dateien mit Drag-and-Drop herüber oder wähle die Dateien manuell im Feld für Binärdateien.
-
Um Benutzer*innen darüber zu informieren, dass das Release nicht produktionsbereit und möglicherweise instabil ist, wähle optional Dies ist eine Vorabversion aus.
-
Wähle optional Als neueste Version festlegen aus. Wenn du diese Option nicht auswählst, wird die neueste Versionsbezeichnung automatisch auf Basis der semantischen Versionierung zugewiesen.
-
Wenn GitHub Discussions für das Repository aktiviert ist, erstelle optional eine Diskussion für das Release.
- Wähle Diskussion für dieses Release erstellen aus.
- Wähle das Dropdownmenü Kategorie und dann eine Kategorie für die Releasediskussion aus.
-
Wenn du dein Release veröffentlichen möchtest, klicke auf Release veröffentlichen. Wenn du später an dem Release arbeiten möchtest, klicke auf Entwurf speichern.
Konfigurieren von automatisch generierten Versionshinweisen
-
Navigieren Sie auf GitHub zur Hauptseite des Repositorys.
-
Wähle über der Dateiliste das Dropdownmenü Add file aus, und klicke dann auf Create new file.
Alternativ kannst du in der Dateistrukturansicht links auf klicken.
-
Gib in das Feld für den Dateinamen
.github/release.yml
ein. Dadurch wird eine neue Datei namensrelease.yml
im Verzeichnis.github
erstellt. -
Gib in der Datei mithilfe der nachstehenden Konfigurationsoptionen in YAML die Pull-Request-Bezeichnungen und Autoren an, die du aus diesem Release ausschließen möchtest. Du kannst auch neue Kategorien erstellen und die Pull-Request-Bezeichnungen auflisten, die in jede dieser Kategorien einbezogen werden sollen.
Konfigurationsoptionen
Parameter | BESCHREIBUNG |
---|---|
changelog.exclude.labels | Eine Liste von Bezeichnungen, die ausschließen, dass ein Pull Request in den Versionshinweisen angezeigt wird. |
changelog.exclude.authors | Eine Liste der Benutzer*innen- oder Bot-Anmeldehhandles, deren Pull Requests aus Versionshinweisen ausgeschlossen werden sollen. |
changelog.categories[*].title | Erforderlich. Der Titel einer Kategorie von Änderungen in Versionshinweisen. |
changelog.categories[*].labels | Erforderlich. Bezeichnungen, die einen Pull Request für diese Kategorie qualifizieren. Verwende * als Catch-All für Pull Requests, die keinen der vorherigen Kategorien entsprechen. |
changelog.categories[*].exclude.labels | Eine Liste der Bezeichnungen, die eine Pull Request ausschließen, die in dieser Kategorie angezeigt wird. |
changelog.categories[*].exclude.authors | Eine Liste der Benutzer*innen- oder Bot-Anmeldehhandles, deren Pull Requests aus dieser Kategorie ausgeschlossen werden sollen. |
Beispielkonfigurationen
Eine Konfiguration für ein Repository, das SemVer-Releases kennzeichnet
# .github/release.yml changelog: exclude: labels: - ignore-for-release authors: - octocat categories: - title: Breaking Changes 🛠 labels: - Semver-Major - breaking-change - title: Exciting New Features 🎉 labels: - Semver-Minor - enhancement - title: Other Changes labels: - "*"
# .github/release.yml
changelog:
exclude:
labels:
- ignore-for-release
authors:
- octocat
categories:
- title: Breaking Changes 🛠
labels:
- Semver-Major
- breaking-change
- title: Exciting New Features 🎉
labels:
- Semver-Minor
- enhancement
- title: Other Changes
labels:
- "*"
Eine Konfiguration für ein Repository, das keine Pull Requests taggt, aber in der automatisierte Dependabot-Pull Requests in Versionshinweisen getrennt werden sollen (labels: '*'
ist erforderlich, um eine Catchall-Kategorie anzuzeigen)
# .github/release.yml changelog: categories: - title: 🏕 Features labels: - '*' exclude: labels: - dependencies - title: 👒 Dependencies labels: - dependencies
# .github/release.yml
changelog:
categories:
- title: 🏕 Features
labels:
- '*'
exclude:
labels:
- dependencies
- title: 👒 Dependencies
labels:
- dependencies