Jenkins no puede cancelar el trabajo en la falla de connection git

Tengo una configuration de trabajo en mi Jenkins que copy un repository git (en la web), a nuestro git local (intranet). Funciona el 99% del time sin problemas.

Pero de vez en cuando, como nuestra connection a Internet no es tan buena, no se conecta al repository remoto. El problema no está exactamente en el problema de connection, que es un hecho. El problema radica en cómo lo maneja Jenkins.

Ahora está configurado para ejecutarse cada 15 minutos buscando cambios en el repository remoto. (Aún no logramos establecer un webhook) Nueve veces de cada diez, no habrá y finalizará con "Sin cambios, OK".

Cuando la connection a Internet no es tan buena, la consulta de git tendrá un time de espera, pero en lugar de abortar el trabajo y volver a ejecutarlo 15 minutos después, se volverá loco e intentará download todo el repository, que tiene casi 200 MB de tamaño, y por supuesto, se bloqueará porque, bueno, la connection en ese punto no es buena. ¿La peor parte? El trabajo no se ejecutará nuevamente, hasta que lo haga manualmente.

¿Algún consejo sobre cómo solucionar este comportamiento? A continuación se muestra un logging que muestra el comportamiento extraño de Jenkins.

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.launchCommandWithCnetworkingentials(CliGitAPIImpl.java:1525) 16:40:10 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:65) 

Puede que esta no sea la solución más gloriosa, pero establecer el Recuento de Rebashs en Opciones Avanzadas del Proyecto puede aliviar algunos de sus problemas. Si se establece Reintentar recuento , Jenkins volverá a intentar verificar el código del repository una cierta cantidad de veces (lo que sea que esté configurado) cuando falle una compilation.

Si el server de Jenkins está fallando, lo que parece que podría estar haciendo con los detalles que proporcionó, entonces le sugiero que implemente un webhook de inmediato y realice comstackciones manuales hasta que se repare el process. No hay nada de malo en hacer comstackciones manuales durante un corto período de time. Todavía es una práctica de CI aceptable, aunque la automation completa es ideal.