Jenkins bricht Job bei Ausfall der Git-Verbindung nicht ab

Question

Ich habe ein Job-Setup in meinem Jenkins, das ein Git-Repository (im Web) zu unserem lokalen (Intranet) Git kopiert. Es funktioniert 99% der Zeit ohne Probleme.

Aber hin und wieder, da unsere Internetverbindung nicht so gut ist, kann keine Verbindung zum Remote-Repository hergestellt werden. Das Problem liegt nicht genau in dem Verbindungsproblem, das gegeben ist. Das Problem liegt darin, wie Jenkins damit umgeht.

Es ist jetzt so eingestellt, dass es alle 15 Minuten nach Änderungen im Remote-Repo sucht. (Es ist uns noch nicht gelungen, einen Webhook einzurichten) Neun von zehn Tagen wird es nicht geben und es endet mit "Keine Änderungen - OK".

Wenn die Internetverbindung nicht so gut ist, wird die Abfrage auf git Timeout, aber anstatt den Job abzubrechen, und es 15 Minuten später wieder laufen, wird es verrückt und versuchen, den gesamten Repo, der fast 200 MB ist in der Größe, und natürlich wird es abbrechen - gut, die Verbindung an diesem Punkt ist nicht gut. Der schlechteste Teil? Der Job wird nicht erneut ausgeführt, bis ich ihn manuell ausführe.

Gibt es Hinweise, wie Sie dieses Verhalten beheben können? Unten ist ein Protokoll, das Jenkins seltsames Verhalten zeigt.

16:30:09 > git fetch --tags --progress https://xxxxxx@git.ng.bluemix.net/yyy/mmmmm.git +refs/heads/*:refs/remotes/origin/* 
16:40:09 ERROR: Timeout after 10 minutes 
16:40:09 ERROR: Error cloning remote repo 'origin' 
16:40:10 hudson.plugins.git.GitException: Command "git fetch --tags --progress https://xxxxxx@git.ng.bluemix.net/yyy/mmmmm.git +refs/heads/*:refs/remotes/origin/*" returned status code 143: 
16:40:10 stdout: 
16:40:10 stderr: remote: Counting objects: 45507, done.   
16:40:10 remote: Compressing objects: 0% (1/397)   
remote: Compressing objects: 1% (4/397)   
remote: Compressing objects: 2% (8/397)   
remote: Compressing objects: 3% (12/397)   
remote: Compressing objects: 4% (16/397)   
[...] 
Receiving objects: 54% (24849/45507), 83.98 MiB | 82.00 KiB/s 
Receiving objects: 54% (24849/45507), 84.04 MiB | 84.00 KiB/s 
16:40:10 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1799) 
16:40:10 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1525) 
16:40:10 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:65) 

Answer 1

Dies könnte die herrlichste Lösung nicht, aber die Retry unter Erweiterte Projektoptionen könnten einige Ihrer Leiden lindern Count Einstellung. Wenn Wiederholungsanzahl festgelegt ist, wird Jenkins versuchen, den Code aus dem Repository eine bestimmte Anzahl von Wiederholungen (egal was gesetzt ist) auszuführen, wenn ein Build fehlschlägt.

Wenn der Jenkins-Server tatsächlich abstürzt, was nach den von Ihnen angegebenen Details klingt, würde ich vorschlagen, sofort einen Webhook zu implementieren und manuelle Builds zu erstellen, bis der Prozess behoben ist. Es ist nichts falsch daran, manuelle Builds für kurze Zeit zu erstellen. Es ist immer noch eine akzeptable CI-Praxis, obwohl eine vollständige Automatisierung ideal ist.