Beenden Sie mvn release, das wiederholte Jenkins-Builds auslöst

Lesezeit: 2 Minuten

[Releasing via the maven-release-plugin, Git repos hosted on Atlassian Stash which triggers build pipeline in Jenkins.]

Gibt es eine Möglichkeit zu verhindern, dass die Freigabe einen neuen Lauf der Pipeline auslöst? Dies geschieht, weil die freigegebenen pom-Dateien wieder an Stash übergeben werden. Da gerade ein Build stattgefunden hat (um zum Release-Job zu gelangen), ist dies völlig unnötig, da sich gegenüber dem letzten Build nur die Versionsnummern der Pom-Datei geändert haben.

Das Jenkins-Git-Plugin kann so konfiguriert werden, dass bestimmte Commit-Nachrichten ignoriert werden. [maven-release-plugin] in Ihrem Fall.

Geben Sie hier die Bildbeschreibung ein

Beachten Sie, dass das Beispiel im Hilfetest für Ignorieren von Commits einige Probleme hat, versuchen Sie es mit meiner Version: ^(?s)\[maven-release-plugin\].*

Danke @blackbuild.

Das hat nicht wirklich funktioniert, denke ich, weil wir nicht von Jenkins abfragen, sondern einen Build von Stash (Commits) auslösen.

Stash-Webhook zu Jenkins

In unserem Fall denke ich, dass die Antwort darin besteht, Release-Builds mit einem bestimmten (eingeschränkten) Benutzer durchzuführen, der dann vom Stash-Ende aus ignoriert werden kann.

Committers zu ignorieren

Ich denke jedoch, dass Ihre Antwort gut für diejenigen ist, die Git-Repo direkt vom Jenkins-Server abfragen 🙂

Vielen Dank! Andreas

  • Es sollte funktionieren. Der Webhook teilt Jenkins nur mit, dass alle Repos, die dieses geänderte Repository verwenden, zum Abfragen zugelassen werden. Überprüfen Sie also, ob der Commit-Kommentar mit dem Kommentar des Release-Builds übereinstimmt.

    – Schwarzbau

    3. September 2015 um 10:54 Uhr

  • @andrewEells hattest du überhaupt Glück damit? 🙂

    – Hafis

    16. März 2017 um 16:44 Uhr

Ich stecke mit einer alten Version von Jenkins (v1.487) fest und die Version des Git-Plugins, die wir haben, hat keine Option für Additional behaviors.

Ich musste eine ähnliche, aber nicht genau die gleiche Lösung wie @Andrew Eells verwenden.

Ich habe Jenkins, der ein Git-Repo abfragt und erstellt, wenn Änderungen gefunden werden. Mein Build befand sich für eine Weile in einer Endlosschleife und wurde neu erstellt, wenn jemals das Release-Plug-in a drückte pom.xml Update am Ende des Builds.

Um dies zu lösen, habe ich einen bestimmten Benutzer in Github eingerichtet (hier nicht mit Stash, aber konzeptionell gleich), um die Builds immer durchzuführen. Ich habe es dann dem erweiterten Abschnitt des Git-Plugins in Jenkins unter hinzugefügt Excluded Users. Im Grunde dasselbe wie Andrews Antwort, aber so konfiguriert, dass der Benutzer vom Jenkins-Ende anstelle von Stash ignoriert wird.

Geben Sie hier die Bildbeschreibung ein

1014660cookie-checkBeenden Sie mvn release, das wiederholte Jenkins-Builds auslöst

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy