Jenkins construye continuamente el esclavo de Windows incluso sin cambios en el repositorio

Question

Tengo dos trabajos de Jenkins vinculados a un esclavo de Windows en particular que se crean continuamente. Están configurados para sondear el SCM de Git con una expresión cron de * * * * *, pero se compilará cada minuto, incluso si no ha habido cambios en el repositorio de Git. En el registro de votación de Git para ambos trabajos veo lo siguiente:

Started on 20-Jan-2012 10:57:10 
Using strategy: Default 
[poll] Last Build : #4179 
[poll] Last Built Revision: Revision 581837483fc583126d8fde7760c88062d3aa2cfa (origin/HEAD, origin/master) 
Last build was not on tied node, forcing rebuild. 
Done. Took 8 ms 
Changes found 

En particular, la línea diciendo Last build was not on tied node, forcing rebuild. parece sospechoso. Puedo ver algunos informes de cosas similares al buscar en Google este término pero sin soluciones.

Otros esclavos de Windows no parecen tener el mismo problema, así que no estoy seguro de que sea un problema de Windows.

¿Alguien tiene alguna idea de lo que podría causar esto o lo que puedo hacer para resolverlo?

Answer 1

¿Está absolutamente seguro de que el trabajo ha estado relacionado con un esclavo?

Como una solución a un problema de aspecto similar con el mensaje "Última compilación no fue atada en el nodo, obligando a reconstruir", atar el trabajo a un nodo esclavo se ha sugerido: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=334069

Answer 2

Bien, acabo resuelto éste para nuestro servidor de compilación (que se ejecuta Hudson) con la ayuda de: http://web.archiveorange.com/archive/v/OkDctYWEcMGCgTIDY2Av

Cuando se ata un trabajo a una configuración de esclavos, en el fichero de configuración siguiente se escribe

<assignedNode>hudson-slave1</assignedNode> 

Cuando una acumulación termina, se crea un archivo

<job>/builds/<build-no>/build.xml. 

Este archivo tiene

<builtOn>hudson-slave1</builtOn> 

me di cuenta de una cosa extraña. Si ve la etiqueta que imprimí arriba, dice "hudson-slave1" que pertenece al nodo "hudson-slave1". Extrañamente, el nodo "hudson-slave1" tiene dos etiquetas "build2" y "hudson-slave2". No hay tal etiqueta "Hudson-esclavo1" (ver la primera imagen ). **

En nuestro caso la acumulación fue atado a un nodo "BUILDDEV3", que tuvo su etiqueta como "grandes constructores".

Agregué el nombre del nodo a la lista de etiquetas (cambiando la lista de etiquetas a "constructores principales BUILDDEV3") e inmediatamente comenzó a comportarse.

Parece que el nombre del nodo se compara con las etiquetas para determinar si la última compilación se realizó en el nodo vinculado.

Probablemente se trata de un error que se ha omitido porque, supongo, si se vincula a una etiqueta, entonces funcionará, ya que la etiqueta se comparará con la etiqueta.

Así, en resumen, agregue el nombre de nodo a la lista de etiquetas y debería funcionar.

Answer 3

acabo encontrado con este problema con Hudson v2.2.1 (sí, sé que es una versión antigua). No estoy seguro de qué desencadenó las compilaciones fuera de control, ya que no parece que los cambios de configuración se alineen con el inicio de la fuga. Sin embargo, he encontrado una solución alternativa (adicional).

En la página de configuración del trabajo, hay una opción (casilla de verificación) para "Restringir dónde se puede ejecutar este proyecto", con dos opciones (botón de opción) para seleccionar los medios de restricción: "Menú de nodo y etiqueta" o "Expresiones avanzadas de nodo y etiqueta", una de las cuales debe seleccionarse.

Cuando se selecciona la segunda de esas opciones, "expresiones de nodo avanzada y Label", un campo de texto de forma libre parece que le permite introducir una expresión lógica que combina términos de

• el conjunto de nombres de nodos esclavos ("BUILDDEV3" en la respuesta de @Camy), unión
• el conjunto de todos los valores esclavos de las etiquetas ("constructores principales" en la respuesta de @Camy).

Por ejemplo, major-builders && !BUILDDEV3.

Cuando la primera de estas opciones, se selecciona "Nodo y el menú de etiquetas", una lista de selección parece que le permite elegir un valor de una lista que contenga los términos de:

• el conjunto de esclavos nombres de nodo, unión
• la lista de todos los valores de la etiqueta de esclavos, unión
• el conjunto de todas las expresiones definidas actualmente en cualquier trabajo del mecanismo de "nodo avanzada y expresiones de etiqueta".

Observe que el conjunto de nombres de los nodos esclavos se tratan inherentemente como etiquetas esclavas. @ Sugerencia de Campey es no meterse con el mecanismo de selección, pero para agregar explícitamente el nombre del nodo esclavo a la lista de etiquetas para cada esclavo. Esto funcionará, pero tiene posibles efectos secundarios, por ejemplo, si cambia el nombre de un nodo. No lo he intentado pero puede incluso provocar que aparezcan duplicados en la lista de términos de selección para el selector de envío. Prefiero evitar la captura de información redundante.

Mi solución alternativa es no siempre seleccionar los nombres de nodo esclavo implícitas, pero sólo usar etiquetas o expresiones que contienen sólo las etiquetas en el mecanismo de selección, independientemente o la que elijas. Esto nunca será redundante.

Por ejemplo, para expresar el ejemplo anterior: major-builders && !BUILDDEV3, donde "major-builders" es una etiqueta y "BUILDDEV3" es un nombre de nodo, uno debería agregar una etiqueta de nodo única al nodo "BUILDDEV3" tal como "NOTHERE", y luego usa la expresión, major-builders && !NOTHERE.