Jenkins crea continuamente su Windows slave anche senza modifiche al repository

Question

Ho due processi Jenkins legati a un particolare slave Windows che viene creato continuamente. Sono impostati per eseguire il polling di Git SCM con un'espressione cron di * * * * * ma verranno creati ogni minuto anche se non sono state apportate modifiche al repository Git. Nel registro polling Git sia per i lavori vedo il seguente:

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 

In particolare la linea dicendo Last build was not on tied node, forcing rebuild. sembra sospetto. Riesco a vedere alcune segnalazioni di cose simili quando si utilizza questo termine su Google ma non ci sono soluzioni.

Altri slave di Windows non sembrano avere lo stesso problema, quindi non sono sicuro che si tratti di un problema di Windows.

Qualcuno ha idea di cosa potrebbe causare questo o quello che posso fare per risolverlo?

Answer 1

Sei assolutamente sicuro che il lavoro sia stato collegato a uno schiavo?

Come soluzione a un problema simile alla ricerca con il messaggio "Ultimo build non era sul nodo legato, costringendo la ricostruzione", legando il lavoro a un nodo slave è stato suggerito: https://bugs.eclipse.org/bugs/show_bug.cgi?format=multiple&id=334069

Answer 2

Va bene, ho appena risolto questo uno per la nostra build server (in esecuzione Hudson) con l'aiuto di: http://web.archiveorange.com/archive/v/OkDctYWEcMGCgTIDY2Av

Quando si legare un posto di lavoro ad una configurazione di schiavi, nel file di configurazione segue è scritto

<assignedNode>hudson-slave1</assignedNode> 

Quando una costruzione è terminata, viene creato un file

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

Questo file ha

<builtOn>hudson-slave1</builtOn> 

ho notato una cosa strana. Se vedi l'etichetta che ho stampato sopra, lo dice "hudson-slave1" che appartiene al nodo "hudson-slave1". Stranamente, il nodo "hudson-slave1" ha due etichette "build2" e "hudson-slave2". Non esiste un'etichetta "hudson-slave1" (vedere il primo foto). **

Nel nostro caso accumulo era legata ad un nodo "BUILDDEV3" che aveva la sua etichetta come "grandi costruttori".

Ho aggiunto il nome del nodo all'elenco delle etichette (cambiando l'elenco delle etichette in "buildbuilder BUILDDEV3") e immediatamente ha iniziato a comportarsi.

Sembra che il nome del nodo sia confrontato con le etichette per determinare se l'ultima build era sul nodo legato.

Questo è probabilmente un errore che è stato perso perché, presumo, se si lega a un'etichetta, quindi funzionerà come l'etichetta verrà confrontata con l'etichetta.

Quindi, in breve, aggiungere il nome del nodo all'elenco delle etichette e dovrebbe funzionare.

Answer 3

Ho appena riscontrato questo problema con Hudson v2.2.1 (sì, so che è una versione antica). Non sono sicuro di cosa abbia scatenato le build instabili, poiché nessuna modifica alla configurazione sembra allinearsi con l'inizio della fuga. Tuttavia, ho trovato un (aggiuntivo) work-around.

Nella pagina di configurazione del lavoro, è disponibile un'opzione (casella di controllo) per "Limita il punto in cui è possibile eseguire questo progetto", con due opzioni (pulsante di scelta) per selezionare il metodo di restrizione: "Menu Nodo e etichetta" o "Espressioni avanzate di nodi e etichette", una delle quali deve essere selezionata.

Quando viene selezionata la seconda di queste opzioni, "Nodo avanzata e Label espressioni",, un campo di testo in formato libero emerge che permette di inserire un'espressione logica che unisce i termini da

• l'insieme di nomi di nodi slave ("BUILDDEV3" nella risposta di @ Campey), unione
• l'insieme di tutti i valori di etichetta slave ("major-builders" nella risposta di @ Campey).

Ad esempio, major-builders && !BUILDDEV3.

Quando la prima di queste opzioni, è selezionato "Node e il menu etichetta",, un elenco di selezione sembra che permette di scegliere un valore da un elenco che contiene i termini da:

• l'insieme di schiavi nomi dei nodi, sindacali
• l'elenco di tutti i valori di etichetta di schiavi, unione
• l'insieme di tutte le espressioni attualmente definiti in qualsiasi lavoro dal meccanismo di "Node avanzate e le espressioni Label".

Si noti che l'insieme di nomi di nodi slave sono intrinsecamente trattati come etichette slave. @ Il suggerimento di Campey è di non compromettere il meccanismo di selezione, ma di aggiungere esplicitamente il nome del nodo slave all'elenco delle etichette per ogni slave. Questo funzionerà, ma ha potenziali effetti collaterali, ad esempio, se si rinomina un nodo. Non l'ho provato, ma potrebbe persino causare la visualizzazione di duplicati nell'elenco dei termini di selezione per il selettore di invio. Preferisco evitare l'acquisizione di informazioni ridondanti.

La mia soluzione consiste nel non selezionare mai i nomi di nodi slave impliciti, ma utilizzare solo etichette o espressioni contenenti solo etichette nel meccanismo di selezione, indipendentemente o quale si scelga. Questo non sarà mai ridondante.

Ad esempio, per esprimere l'esempio dato in precedenza: major-builders && !BUILDDEV3, dove "major-builders" è un'etichetta e "BUILDDEV3" è un nome nodo, si dovrebbe aggiungere un'etichetta nodo univoca al nodo "BUILDDEV3" tale come "NOTHERE", quindi utilizzare l'espressione major-builders && !NOTHERE.