release please
v16.15.0
Release Please automatisiert die CHANGELOG-Generierung, die Erstellung von GitHub-Releases und Versionsänderungen für Ihre Projekte.
Dazu wird Ihr Git-Verlauf analysiert, nach herkömmlichen Commit-Nachrichten gesucht und Release-PRs erstellt.
Es kümmert sich nicht um die Veröffentlichung an Paketmanager oder um die komplexe Filialverwaltung.
Anstatt das, was gelandet ist, kontinuierlich in Ihrem Standardzweig freizugeben, verwaltet release-please die Release-PRs:
Diese Release-PRs werden auf dem neuesten Stand gehalten, wenn zusätzliche Arbeiten zusammengeführt werden. Wenn Sie bereit sind, eine Veröffentlichung mit Tags zu versehen, führen Sie einfach die Veröffentlichungs-PR zusammen. Sowohl Squash-Merge- als auch Merge-Commits funktionieren mit Release-PRs.
Wenn die Release-PR zusammengeführt wird, führt release-please die folgenden Schritte aus:
Aktualisiert Ihre Changelog-Datei (zum Beispiel CHANGELOG.md ) zusammen mit anderen sprachspezifischen Dateien (zum Beispiel package.json ).
Markiert den Commit mit der Versionsnummer
Erstellt eine GitHub-Version basierend auf dem Tag
Anhand der Statusbezeichnung auf der PR selbst können Sie erkennen, wo sich die Release-PR in ihrem Lebenszyklus befindet:
autorelease: pending ist der Anfangsstatus der Release-PR, bevor sie zusammengeführt wird
autorelease: tagged bedeutet, dass die Release-PR zusammengeführt und die Veröffentlichung in GitHub getaggt wurde
autorelease: snapshot ist ein spezieller Status für Snapshot-Versions-Bumps
autorelease: published bedeutet, dass ein GitHub-Release basierend auf dem Release PR veröffentlicht wurde ( release-please fügt dieses Tag nicht automatisch hinzu, wir empfehlen es jedoch als Konvention für Veröffentlichungstools ).
Release Please geht davon aus, dass Sie herkömmliche Commit-Nachrichten verwenden.
Die wichtigsten Präfixe, die Sie beachten sollten, sind:
fix: stellt Fehlerbehebungen dar und korreliert mit einem SemVer-Patch.
feat: stellt eine neue Funktion dar und entspricht einem SemVer-Minor.
feat!: oder fix!: , refactor!: usw., die eine bahnbrechende Änderung darstellen (gekennzeichnet durch das ! ) und zu einem SemVer-Major führen.
Wir empfehlen dringend , beim Zusammenführen von Pull-Anfragen Squash-Merges zu verwenden. Ein linearer Git-Verlauf macht es viel einfacher:
Verlauf verfolgen – Commits werden nach Zusammenführungsdatum sortiert und nicht zwischen Pull-Anfragen gemischt
Fehler finden und beheben – git bisect ist hilfreich, um herauszufinden, welche Änderung einen Fehler verursacht hat
Kontrollieren Sie das Release-Please-Änderungsprotokoll – wenn Sie eine PR zusammenführen, erhalten Sie möglicherweise Commit-Nachrichten, die im Rahmen der PR sinnvoll sind, aber keinen Sinn ergeben, wenn sie im Hauptzweig zusammengeführt werden. Zum Beispiel könnten Sie feat: introduce feature A und dann fix: some bugfix introduced in the first commit . Das fix -Commit ist für die Versionshinweise eigentlich irrelevant, da im Hauptzweig nie ein Fehler aufgetreten ist.
Behalten Sie einen sauberen Hauptzweig bei – wenn Sie so etwas wie eine Rot/Grün-Entwicklung verwenden (einen fehlgeschlagenen Test in Commit A erstellen und dann in Commit B beheben) und Merge (oder Rebase-Merge) verwenden, dann wird es in Ihrem Hauptzweig Zeitpunkte geben wo Tests nicht bestanden werden.
Mit „Release Please“ können Sie mehrere Änderungen in einem einzigen Commit mithilfe von Fußzeilen darstellen:
Kunststück: Fügt der Krypto v4-UUID hinzu Dadurch wird der Bibliothek Unterstützung für v4-UUIDs hinzugefügt. fix(utils): Unicode löst keine Ausnahme mehr aus PiperOrigin-RevId: 345559154 BREAKING-CHANGE: Die Codierungsmethode löst keine Auslösungen mehr aus. Quelllink: googleapis/googleapis@5e0dcb2 feat(utils): Kodierung aktualisieren, um Unicode zu unterstützen PiperOrigin-RevId: 345559182 Quelllink: googleapis/googleapis@e5eef86
Die obige Commit-Nachricht enthält:
ein Eintrag für die Funktion „Fügt v4-UUID zu Krypto hinzu“ .
einen Eintrag für den Fix „Unicode löst keine Ausnahme mehr aus“ , zusammen mit einem Hinweis, dass es sich um eine bahnbrechende Änderung handelt.
ein Eintrag für die Funktion „Encode aktualisieren, um Unicode zu unterstützen“ .
Wenn ein Commit für den Hauptzweig Release-As: xxx (Groß-/Kleinschreibung wird nicht beachtet) im Commit-Text enthält, öffnet „Release Please“ einen neuen Pull-Request für die angegebene Version.
Beispiel für einen leeren Commit:
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0" führt zu der folgenden Commit-Nachricht:
Aufgabe: 2.0.0 veröffentlichen Release-As: 2.0.0
Wenn Sie einen Pull-Request zusammengeführt haben und die Commit-Nachricht ändern möchten, die zum Generieren der Versionshinweise für diesen Commit verwendet wurde, können Sie den Text der zusammengeführten Pull-Requests bearbeiten und einen Abschnitt wie den folgenden hinzufügen:
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
Wenn Release Please das nächste Mal ausgeführt wird, wird dieser Überschreibungsabschnitt anstelle der zusammengeführten Commit-Nachricht als Commit-Nachricht verwendet.
Release Please erstellt eine Release-Pull-Anfrage, nachdem es feststellt, dass der Standardzweig seit der letzten Version „freigebbare Einheiten“ enthält. Eine freigebbare Einheit ist ein Commit für den Zweig mit einem der folgenden Präfixe: „feat“, „fix“ und „deps“. (Ein „Chore“- oder „Build“-Commit ist keine freigebbare Einheit.)
Einige Sprachen haben ihre spezifische Konfiguration der lösbaren Einheiten. „docs“ ist beispielsweise ein Präfix für freigebbare Einheiten in Java und Python.
autorelease: pending oder autorelease: triggered -Label vorhanden ist Überprüfen Sie vorhandene Pull-Anfragen mit der Bezeichnung autorelease: pending oder autorelease: triggered “. Aufgrund von GitHub-API-Fehlern ist es möglich, dass das Tag in einer früheren Version nicht korrekt entfernt wurde und Release Please davon ausgeht, dass die vorherige Version noch aussteht. Wenn Sie sicher sind, dass keine Veröffentlichung aussteht, entfernen Sie die Bezeichnung autorelease: pending oder autorelease: triggered .
Für Benutzer der GitHub-Anwendung erstellt „Release Please“ keinen neuen Pull-Request, wenn ein vorhandener Pull-Request mit der Bezeichnung autorelease: pending vorhanden ist. Um diesen Fall zu bestätigen, suchen Sie nach einer Pull-Anfrage mit der Bezeichnung. (Es ist sehr wahrscheinlich, dass es sich um die neueste Release-Pull-Anfrage handelt.) Wenn Sie eine Release-Pull-Anfrage mit der Bezeichnung finden und diese nicht veröffentlicht wird (oder bereits veröffentlicht wird), entfernen Sie die Bezeichnung autorelease: pending “ und führen Sie „Release Please“ erneut aus.
Wenn Sie der Meinung sind, dass Release Please die Erstellung eines Release-PR verpasst hat, nachdem ein Pull-Request mit einer freisetzbaren Einheit zusammengeführt wurde, führen Sie bitte release-please erneut aus. Wenn Sie die GitHub-Anwendung verwenden, fügen Sie der zusammengeführten Pull-Anfrage die Bezeichnung release-please:force-run hinzu. Wenn Sie die Aktion verwenden, suchen Sie nach dem fehlgeschlagenen Aufruf und wiederholen Sie die Ausführung des Workflows. Release Please wird die Pull-Anfrage sofort bearbeiten, um freigebbare Einheiten zu finden.
Release Please automatisiert Releases für die folgenden Arten von Repositorys:
| Freigabetyp | Beschreibung |
|---|---|
bazel | Ein Bazel-Modul mit einem MODULE.bazel und einem CHANGELOG.md |
dart | Ein Repository mit einer pubspec.yaml und einer CHANGELOG.md |
elixir | Ein Repository mit einer mix.exs und einer CHANGELOG.md |
go | Ein Repository mit einer CHANGELOG.md |
helm | Ein Repository mit einem Chart.yaml und einem CHANGELOG.md |
java | Eine Strategie, die nach jeder Veröffentlichung eine SNAPSHOT-Version generiert |
krm-blueprint | Ein kpt-Paket mit einer oder mehreren KRM-Dateien und einer CHANGELOG.md |
maven | Strategie für Maven-Projekte, generiert nach jeder Veröffentlichung eine SNAPSHOT-Version und aktualisiert pom.xml automatisch |
node | Ein Node.js-Repository mit package.json und CHANGELOG.md |
expo | Ein Expo-basiertes React Native-Repository mit package.json, app.json und CHANGELOG.md |
ocaml | Ein OCaml-Repository, das eine oder mehrere opam- oder esy-Dateien und eine CHANGELOG.md enthält |
php | Ein Repository mit einer Composer.json und einer CHANGELOG.md |
python | Ein Python-Repository mit setup.py, setup.cfg, CHANGELOG.md und optional einem pyproject.toml und einem <project>/__init__.py |
ruby | Ein Repository mit einer version.rb und einer CHANGELOG.md |
rust | Ein Rust-Repository mit einer Cargo.toml (entweder als Crate oder Workspace, wobei zu beachten ist, dass Workspaces eine manifestgesteuerte Version und das „Cargo-Workspace“-Plugin erfordern) und einer CHANGELOG.md |
sfdx | Ein Repository mit einer sfdx-project.json und einer CHANGELOG.md |
simple | Ein Repository mit einer version.txt und einer CHANGELOG.md |
terraform-module | Ein Terraform-Modul mit einer Version in der README.md und einer CHANGELOG.md |
Es gibt verschiedene Möglichkeiten, Release-Please bereitzustellen:
Der einfachste Weg, Release Please auszuführen, ist als GitHub-Aktion. Installations- und Konfigurationsanweisungen finden Sie unter googleapis/release-please-action.
Alle Konfigurationsoptionen finden Sie unter Ausführen der Release-Please-CLI.
Es steht eine Probot-Anwendung zur Verfügung, mit der Sie Release Please als GitHub-App bereitstellen können. Installations- und Konfigurationsanweisungen finden Sie unter github.com/googleapis/repo-automation-bots.
Release Please prüft die Commits seit Ihrem letzten Release-Tag. Es kann sein, dass Ihre früheren Versionen nicht gefunden werden. Der einfachste Weg, Ihr Repository zu integrieren, besteht darin, eine Manifestkonfiguration zu booten.
Release Please bietet mehrere Konfigurationsoptionen, mit denen Sie Ihren Release-Prozess individuell anpassen können. Weitere Informationen finden Sie in der Datei „customizing.md“.
Release Please unterstützt auch die Freigabe mehrerer Artefakte aus demselben Repository. Weitere Informationen finden Sie unter manifest-releaser.md.
Unsere Client-Bibliotheken folgen dem Veröffentlichungsplan von Node.js. Bibliotheken sind mit allen aktuellen aktiven und Wartungsversionen von Node.js kompatibel.
Client-Bibliotheken, die auf einige End-of-Life-Versionen von Node.js abzielen, sind verfügbar und können über npm dist-tags installiert werden. Die dist-Tags folgen der Namenskonvention legacy-(version) .
Ältere Node.js-Versionen werden nach besten Kräften unterstützt:
Ältere Versionen werden nicht in der kontinuierlichen Integration getestet.
Einige Sicherheitspatches können möglicherweise nicht zurückportiert werden.
Abhängigkeiten werden nicht auf dem neuesten Stand gehalten und Funktionen werden nicht zurückportiert.
legacy-8 : Installieren Sie Client-Bibliotheken von diesem Dist-Tag für Versionen, die mit Node.js 8 kompatibel sind.
Diese Bibliothek folgt der semantischen Versionierung.
Beiträge willkommen! Siehe Beitragsleitfaden.
Weitere Informationen zum Design der Bibliothek finden Sie unter Design.
Häufige Probleme und Hilfe bei der Fehlerbehebung Ihrer Konfiguration finden Sie unter Fehlerbehebung.
Apache-Version 2.0
Siehe LIZENZ
Dies ist kein offizielles Google-Produkt.
