version-control - jenkins git plugin

Jenkins: SCM desencadena construcciones constantes a pesar de no haber cambios

Question

Tenemos un problema donde, a pesar de no haber cambios en el código, SCM está activando una compilación. SCM sondea los cambios cada 15 minutos y solo debe desencadenar una compilación si se encuentran cambios.

Aquí hay algunos ejemplos de registro de sondeo SCM consecutivo.

Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found

Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found

Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found

Como se puede ver, la revisión es la misma y coincide con la de

Git Build Data

Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop

Estos trabajos se comportaron como se esperaba hasta hace unos días. No hay nada de lo que sepamos que haya cambiado nuestro entorno para causar esto.

Actualicé la última versión de Jenkins (1.539) e instalé complementos anoche en un esfuerzo por resolver esto, pero el comportamiento continúa.

Answer 1

Acabo de encontrarme con Jenkins continuamente construyendo debido a un cambio de SCM, incluso cuando no hubo cambios, y el sondeo ni siquiera estaba activado. Esto puede ser diferente de su situación, pero pensé que aún podría ayudar a compartir mi solución.

El proyecto Out está configurado para compilar utilizando el especificador de rama */integration al igual que todas las otras compilaciones de integración. Sin embargo, después de ver todas las ramas en nuestro repositorio de git de origen, vi que hay dos ramas que coinciden con el especificador */integration . Parece que un desarrollador debe haber empujado erróneamente a una nueva rama con un nombre muy similar:

$git branch --remote | grep integration
  origin/integration
  origin/origin/integration

La solución que solucionó este problema para mí fue especificar la rama completamente, utilizando refs/heads/integration . Supongo que también funcionaría simplemente eliminar la rama ofensiva duplicada, pero especificando la rama exactamente, puedo evitar encontrar el mismo problema en el futuro.

No estoy seguro de que esta sea la misma causa para su problema, pero esto es lo que funcionó para mí, y espero que funcione para alguien más en esta situación.

Answer 2

Estaba experimentando este mismo problema hoy. Comenzó a suceder cuando agregué la tarea de publicación "Eliminar el espacio de trabajo cuando la compilación haya terminado". Quité esa tarea y pareció resolver el problema.

Answer 3

Parece ser reproducible con la última versión del plugin Jenkins GIT 2.0.

Bajar de categoría a la versión 1.x puede solucionar el problema. Aunque también debe revertir la configuración de Jenkins de una copia de seguridad anterior, el complemento de GIT versión 1.x parece no funcionar con el nuevo esquema de configuración 2.0.

Este hilo sugiere habilitar "Encuesta remota rápida" como solución alternativa. En la versión 2.0 se llama "Forzar el sondeo usando el espacio de trabajo", creo.

Referencia al problema de Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-20767

Answer 4

Tenga cuidado con las redirecciones svn, en mi caso tuve el mismo caso que Jenkins no pudo detectar si svn no tiene cambios y siempre se activó.

El problema fue que en mi configuración jenkins svn tenía esta url:

https://xxxx.yyy.es:443/svn/myproject/trunk y su redirección a

http://xxxx.yyy.es:8008/svn/myproject/trunk (no sé por qué)

Jenkins tuvo que configurarse con la última URL para detectar los cambios svn correctamente.

Este es mi problema Resuelto.

http://antuansoft.blogspot.com.es/2014/10/jenkins-pool-smc-always-detect-changes.html

Answer 5

Tuve el mismo problema.

Lo que me lo arregló es que el Registro de sondeo de Git tenía este aspecto:

Started on [date]
Using strategy: Default
[poll] Last Built Revision: Revision [commit#] (origin/develop)
[...]
Found 12 remote heads on ssh://[...]/repo.git
[poll] Latest remote head revision on refs/heads/feature/foo is: [commit#] - already built by 1414
[poll] Latest remote head revision on refs/heads/feature/bar is: [commit#] - already built by 2365
[poll] Latest remote head revision on refs/heads/feature/baz is: [commit#] - already built by 1489
[poll] Latest remote head revision on refs/heads/feature/qux is: [commit#] - already built by 1413
[poll] Latest remote head revision on refs/heads/develop is: [commit#] - already built by 2368
[poll] Latest remote head revision on refs/heads/master is: [commit#]
Done. Took 0.16 sec
Changes found

Observe que la línea para el master no dice "ya construido". Construí la rama master y eso solucionó el problema.