2016-06-14 12 views
1

Ich möchte, dass mein Code-Überprüfungsjob Änderungen ignoriert, die von anderen Jenkins-Jobs stammen, wie zum Beispiel mein Veröffentlichungsjob. Diese Commits können entweder durch den Commit-Benutzer (bevorzugt) oder den Commit-Kommentar-String (auch akzeptabel) identifiziert werden.Wie kann ich Jenkins Gerrit Trigger dazu bringen, die Commits meines CI-Benutzers zu ignorieren?

Grundsätzlich habe ich das gleiche Problem wie der Benutzer, der Ignore Jenkins job if commit message starts with a given string fragte, außer dass ich nicht das Git-Plugin mit Polling verwenden. Stattdessen verwende ich die Gerrit Trigger plugin, die bei jedem neuen Änderungssatz ausgelöst wird.

Ich glaube, der folgende Screenshot enthält die entsprechende Konfiguration des GT-Plugins.

Ich habe im Internet gesucht, aber ich konnte nicht finden, wie dies zu erreichen ist. Ich habe diese Art von Konfiguration für das Git-Plugin gefunden, kann sie aber nicht verwenden, da wir Gerrit verwenden. Daher brauchen wir vor dem Commit Changeset-Triggering statt Polling.

Trigger on "Patchset Created", "Draft published"

Antwort

1

Eine vorgeschlagene Ansatz die "ci skip" plugin zu verwenden war.

Ich habe meine Release-Aufträge so eingerichtet, dass sie [ci skip] in ihre Commit-Nachrichten aufnehmen.

Bei der Verwendung fand ich es tatsächlich noch einen Build ausgelöst. Der Build wird jedoch als "Not Built" beendet, nachdem wir das Commit überprüft haben. Das bedeutet, dass der Build meine Build-History noch verschleiert und immer noch Ressourcen zum Abrufen und Rev-Parsen usw. verbraucht, so dass es für mich eine weniger bevorzugte Lösung ist.

Während dies mein unmittelbares Problem löst, werde ich gerne andere Antworten akzeptieren, da ich nicht ganz glücklich mit diesem bin.

+0

Ist es möglich, Ihren Freigabeauftrag in einen vorgelagerten Job und einen nachgelagerten Job aufzuteilen? Der Upstream holt nicht ab und checkt nur aus. Wenn stabil, wird der Downstream zum Abrufen und Auschecken und Erstellen ausgelöst. – ElpieKay

+0

Interessante Idee, aber nicht sicher, dass ich es verstanden habe. Auf was würde der vorgelagerte Job ausgelöst werden? Und auf was würde es Tests laufen lassen, wenn es die Software noch nicht gebaut hat? – Jolta

+0

der Upstream wird durch Gerrit-Trigger ausgelöst. Der Test hier, ich meine, ist zu überprüfen, ob der Commit ignoriert werden sollte und ob der Build-Teil umgangen werden sollte. – ElpieKay

2

Gerrit Trigger stellt eine Gruppe von Variablen zur Verfügung, in denen Sie den Namen des Commiters, die Commit-Nachricht usw. finden können. Die Lösung besteht darin, die Werte dieser Variablen zu testen und den Build-Job zu beenden, wenn der Test erfolgreich ist. Aber es könnte ein Problem geben, wenn Sie Jenkins V2.3 oder höher verwenden. Auf einige der Variablen kann nicht über $ in der Shell zugegriffen werden. Sie können sich auf die Jenkins V2.3-Versionshinweise beziehen, um dieses Problem zu lösen. Sie könnten das Fragezeichen rechts auf Gerrit event drücken, um die Liste der Variablen zu sehen.

+0

Sie meinen, um diese Prüfungen als benutzerdefinierte Shell-Befehle auszuführen, verwenden Sie Build-Schritt -> Shell ausführen? – Jolta

+1

@Jolta ja. Und der Abruf- und Checkout-Teil könnte auch über Shell-Befehle erfolgen. Daher können Sie zuerst testen und dann entscheiden, ob Sie das Abrufen und Erstellen durchführen. Selbst wenn der Job selbst ausgelöst wird, benötigt es nur wenig Zeit, um den Test zu starten. – ElpieKay

+0

Ich verstehe. Nun, in diesem Fall denke ich, dass ich lieber das Plugin "ci skip" benutze, da ich dann zumindest selbst keine Skripte schreiben muss.=) – Jolta

Verwandte Themen