2016-08-03 23 views
0

Ich habe einen Wrapper-Job in Jenkins erstellt, der stündlich ausgelöst wird, wenn neue Commits in meinem GIT-Repository vorliegen. Dieser Wrapper-Job ruft wiederum 6 andere Downstream-Jobs auf. So ist die Struktur meines Wrapper Jobs (W) ist wie folgt:Ermitteln, welcher nachgelagerte Job fehlgeschlagen ist und Benachrichtigung in Jenkins senden

W -> A -> B -> C -> D -> E -> F

I Jenkins Parameterized Trigger-Plugin bin mit zum Aufnähen ein Job für den anderen, so dass meine Upstream-Jobs fehlschlagen, wenn der Downstream-Job fehlschlägt. Nach Abschluss des letzten nachgelagerten Jobs (F) kopiert der Wrapper-Job (W) die Artefakte von allen nachgelagerten Jobs in seinem aktuellen Arbeitsbereich.

Jetzt, wenn einer meiner nachgelagerten Job (sagen wir E) fehlschlägt, erhalte ich Fehlermeldungen vom fehlgeschlagenen Downstream-Job (E) sowie von allen anderen Upstream-Jobs (D, C, B, A und W) . Also bekomme ich insgesamt 6 Mails und es entsteht etwas Lärm.

Wenn ich die E-Mail-Benachrichtigung nur für den Wrapper-Job (W) aktiviere, erhalte ich eine Einzelfehlerbenachrichtigung, die besagt, dass Job A fehlgeschlagen ist. Dann werde ich die Protokolle von Job A nur überprüfen, um herauszufinden, dass Job B fehlgeschlagen ist, und die Protokollprüfungen fortsetzen, bis ich Job E erreiche.

Wie kann ich die Benachrichtigung anpassen, um eine einzelne Mail zu senden, die den bestimmten nachgelagerten Job identifiziert (in diesem Fall E), der den Fehler verursacht hat?

ODER

Gibt es einen besseren Weg, um die nachgelagerten Arbeitsplätze auslösen, warten, bis alle nachgelagerten Arbeitsplätze abgeschlossen werden und die Artefakte aus allen nachgelagerten Stellen auf den Trigger Job kopieren?

Antwort

0

Schrieb ein Groovy-Skript in Groovy Postbuild, um alle Teilprojekte des Wrapper-Jobs zu durchlaufen und den Wrapper-Job als Fehler zu markieren, wenn eines der Teilprojekte fehlgeschlagen ist.

Die Exit-Kriterien in "Auslöser/Aufruf baut auf anderen Projekten" wurden ebenfalls geändert, um den Job nie als Fehler/Instabil zu markieren. Stattdessen wird der Aufruf, den Job als Fehler zu definieren, im Groovy-Skript selbst basierend auf dem Status der Downstream-Teilprojekte behandelt.