Chronik
0.8.0
Ein schneller Changelog-Generator, der Änderungen aus GitHub-PRs und -Issues bezieht, organisiert nach Labels.
Erstellen Sie ein Änderungsprotokoll von der letzten GitHib-Version bis zum aktuellen Git-HEAD-Tag/Commit für das Git-Repo im aktuellen Verzeichnis:
Chronik
Erstellen Sie ein Änderungsprotokoll mit allen Änderungen von v0.16.0 bis zum aktuellen Git-HEAD-Tag/Commit für das Git-Repo im aktuellen Verzeichnis:
Chronik --since-tag v0.16.0
Erstellen Sie ein Änderungsprotokoll zwischen zwei bestimmten Tags für ein Repo im angegebenen Pfad
chronicle --since-tag v0.16.0 --until-tag v0.18.0 ./path/to/git/repo
Erstellen Sie ein Änderungsprotokoll und erraten Sie die Release-Version anhand der Änderungen im Änderungsprotokoll
Chronik -n
Erraten Sie einfach die nächste Release-Version basierend auf den Änderungen (erstellen Sie kein Änderungsprotokoll).
Chronik nächste Version
curl -sSfL https://raw.githubusercontent.com/anchore/chronicle/main/install.sh | sh -s -- -b /usr/local/bin
...oder Sie können eine Release-Version und ein Zielverzeichnis für die Installation angeben:
curl -sSfL https://raw.githubusercontent.com/anchore/chronicle/main/install.sh | sh -s -- -b
Konfigurationssuchpfade:
.chronicle.yaml
.chronicle/config.yaml
~/.chronicle.yaml
Konfigurationsoptionen (Beispielwerte sind die Standardwerte):
# das Ausgabeformat des Changelogs# wie -o, --output und CHRONICLE_OUTPUT env varoutput: md# alle Protokollierungsausgaben unterdrücken# wie -q ; CHRONICLE_QUIET env varquiet: false# alle Protokollierungsoptionenlog: # strukturierte Protokollierung verwenden # wie CHRONICLE_LOG_STRUCTURED env var structure: false # die Protokollebene # wie CHRONICLE_LOG_LEVEL env var level: „warn“ # Speicherort zum Schreiben der Protokolldatei (Standard ist nicht). eine Protokolldatei haben) # Gleich wie CHRONICLE_LOG_FILE env var file: „“# Erraten Sie, was die nächste Release-Version basierend auf der aktuellen Version und den Änderungen ist (kann nicht mit --until-tag verwendet werden)# Gleich wie –speculate- nächste-Version / -n ; CHRONICLE_SPECULATE_NEXT_VERSION env varspeculate-next-version: false# überschreibt das Start-Git-Tag für das Changelog (standardmäßig wird die letzte Version automatisch erkannt)# dasselbe wie --since-tag / -s ; CHRONICLE_SINCE_TAG env varsince-tag: „“# überschreibt das abschließende Git-Tag für das Changelog (standardmäßig wird das Tag verwendet oder am Git-HEAD festgeschrieben)# dasselbe wie --until-tag / -u ; CHRONICLE_SINCE_TAG env varuntil-tag: „“# Wenn die aktuelle Release-Version < v1.0 ist, wird durch Breaking Changes das Nebenversionsfeld erhöht. Changelog# alle Github-bezogenen Einstellungengithub:
# der zu verwendende Github-Host (Überschreibung für Github-Enterprise-Bereitstellungen) # wie CHRONICLE_GITHUB_HOST env var host: github.com
# Berücksichtigen Sie keine Probleme oder PRs mit einem der angegebenen Labels. # Gleich wie CHRONICLE_GITHUB_EXCLUDE_LABELS env varexclude-labels:
- Duplikat
- Frage
- ungültig
- Wird nicht behoben
- lässt sich nicht reparieren
- loslassen-ignorieren
- Changelog-ignore
- ignorieren
# Betrachten Sie zusammengeführte PRs als mögliche Changelog-Einträge (muss ein passendes Label von einem „github.changes“-Eintrag haben) # Gleich wie CHRONICLE_GITHUB_INCLUDE_PRS env var include-prs: true # Betrachten Sie geschlossene Probleme als Kandidaten-Changelog-Einträge (muss ein passendes Label von einem haben). 'github.changes'-Eintrag) # dasselbe wie CHRONICLE_GITHUB_INCLUDE_ISSUES env var include-issues: true # Probleme können nur für Changelog-Kandidaten berücksichtigt werden, wenn sie verknüpfte PRs haben, die zusammengeführt werden (Hinweis: erfordert NICHT die Festlegung von github.include-issues) # wie CHRONICLE_GITHUB_ISSUES_REQUIRE_LINKED_PRS env var issues-require-linked-prs: false
# Liste der Definitionen, welche Labels, die auf Issues oder PRs angewendet werden, einen Changelog-Eintrag darstellen. Diese Einträge bestimmen auch # den Änderungsprotokollabschnitt, den Änderungsprotokolltitel und das Semver-Feld, das die Änderungsklasse am besten darstellt. # Hinweis: Kann nicht über Umgebungsvariablen festgelegt werden. Änderungen: [......] # Weitere Informationen finden Sie im Abschnitt „Standard-GitHub-Änderungsdefinitionen“. Die konfigurierbare github.changes ist eine Liste von Zuordnungen, die jeweils die folgenden Felder umfassen:
name : [Zeichenfolge] Singular, Kleinbuchstabe, durch Bindestriche getrennt (keine Leerzeichen) Name, der die Änderung am besten darstellt (z. B. „breaking-change“, „security“, „added-feature“, „enhancement“, „new-feature“, usw).
title : [Zeichenfolge] Titel des Abschnitts im Änderungsprotokoll, der alle Einträge auflistet.
semver-field : [string] Änderungseinträge erhöhen das entsprechende Semver-Feld, wenn die nächste Release-Version erraten wird. Zulässige Werte: major , minor oder patch .
labels : [Liste der Zeichenfolgen] alle Issue- oder PR-Labels, die diesem Änderungsabschnitt entsprechen sollten.
Der Standardwert für github.changes ist:
- Name: Sicherheitsfixes Titel: Sicherheitsfixes Semver-Feld: Patch-Bezeichnungen:
- Sicherheit
- Verletzlichkeit
- Name: Titel des hinzugefügten Features: Hinzugefügte Features Semver-Feld: Nebenbezeichnungen:
- Verbesserung
- Besonderheit
- unerheblich
- Name: Bugfix-Titel: Bugfixes Semver-Feld: Patch-Labels:
- Insekt
- beheben
- Fehlerbehebung
- Patch
- Name: Breaking-Feature-Titel: Breaking Changes Semver-Feld: Hauptlabels:
- brechen
- abwärtsinkompatibel
- bahnbrechender Wandel
- Bruchfunktion
- wesentlich
- Name: Titel des entfernten Features: Entfernte Features Semver-Feld: Hauptbezeichnungen:
- ENTFERNT
- Name: Deprecated-Feature-Titel: Deprecated Features Semver-Feld: Nebenbezeichnungen:
– veraltet – Name: unbekannter Titel: Zusätzliche Änderungen 
