2013-02-20 16 views
6

Abbiamo un lavoro Jenkins che costruisce ogni ramo tranne padrone quando ci sono nuovi commit. Questo comportamento può essere configurato tramite 'scelta strategia: inversa' del plugin git in modo che ascolti ogni ramo eccetto un ramo specificato.Come recuperare il nome del ramo git che è stato costruito da Jenkins quando si utilizza inversa strategia di selezione ramo?

Questo funziona molto bene. Ma il problema è che la variabile d'ambiente GIT_BRANCH fa sempre riferimento al ramo escluso ('origine/master' nel nostro caso). Come interrogare il ramo reale che è stato costruito da Jenkins?

Attualmente sto usando una soluzione che ho grep da changelog.xml generato. Ma a volte capita che changelog.xml sia vuoto quando Jenkins passa tra diversi rami e non riesco a trovare queste informazioni. Qual è il modo corretto di recuperare/interrogare da Jenkins il ramo che è stato effettivamente costruito?

risposta

2

Perché git non estrae un ramo solo un commit direttamente si deve effettuare le seguenti operazioni:

Per ottenere l'sha del verificato commit:

git rev-parse HEAD 

per ottenere i tutti i rami che commettono è sotto:

git branch -a --contains SHA 

il fuori messo del secondo comando potrebbe assomigliare a questo

master 
remotes/origin/HEAD -> origin/master 
remotes/origin/develop 
2

sembra che sia un bug Jenkins? È possibile prendere nel vostro script di build il nome del ramo controllato con questo:

git symbolic-ref -q --short HEAD 

realtà Jenkins ha la copia di lavoro in testa staccata, ed è per questo git branch restituisce "nessun ramo". Vedere this quite detailed answer per scavare in riconciliazione con tra un HEAD distaccato e un ramo.

+1

Grazie Carlo. Funziona in una normale area di lavoro git ma non in un'area di lavoro jenkins in cui il comando non restituisce nulla. L'esecuzione di 'git branch' nello spazio di lavoro di jenkins restituisce '* (no branch)'. Probabilmente il ramo scelto deve essere interrogato da Jenkins in qualche modo in quanto sembra effettuare il checkout basato su commit-id nel ramo scelto. – harish

+0

Sì, Jenkins lavora in TESTA distaccata. vedi la mia modifica e la risposta collegata. Sono sicuro che uno dei comandi collegati in esso dovrebbe funzionare. – CharlesB

+0

Questo comando funziona in CMD, ma non nel mio Jenkins, perché? C: \ Tools \ Jenkins \ jobs \ DevOps \ jobs \ Test-GitHub \ workspace> git --version git versione 2.7.0.windows.1 C: \ Tools \ Jenkins \ jobs \ DevOps \ jobs \ Test-GitHub \ workspace> git symbolic-ref -q --short HEAD C: \ Tools \ Jenkins \ jobs \ DevOps \ jobs \ Test-GitHub \ workspace > exit 1 Passo di costruzione 'Esegui comando batch di Windows' contrassegnato come compilato come fallimento Terminato: FAILURE –

17

Ho usato con successo questa sintassi:

GIT_BRANCH=`git rev-parse HEAD | git branch -a --contains | grep remotes | sed s/.*remotes.origin.//` 
+1

Grande! Per chiunque altro, ho dovuto regolare leggermente questo: 'git rev-parse HEAD | git branch -a --contains | telecomandi grep | sed -e 's /.* remotes.origin .//' ' per OS X –

+0

Con il master estratto in un repository al momento con cui sto lavorando, questo risulta in' HEAD -> origine/master \ nmaster' (il '\ n' è davvero una nuova riga nel risultato), che è chiaramente sbagliato. –

+4

Si noti che --contains includerà anche rami più recenti rispetto al codice attualmente estratto. Questo ha funzionato meglio per me: 'git show-ref | grep $ (git rev-parse HEAD) | telecomandi grep | grep -v HEAD | sed -e 's /.* remotes.origin .//' 'E possibilmente reindirizza a' head -n1' se vuoi che scelga arbitrariamente il nome del primo ramo se ci sono più rami che puntano a questo commit. –

0

Non riesco a credere quanto sia difficile questo è. Lo sto facendo anche per Jenkins. I piggypacked fuori la soluzione di Piotr Kuczynski:

branch=`git rev-parse HEAD | git branch -a --contains | grep remotes | sed s/.*remotes.origin.//` 
branch=`echo $branch | awk '{print $NF}'` 

Perché a volte, come Matt Kantor ha sottolineato, la soluzione di Piotr dà un sacco di spazzatura indietro. Ma l'ultima parola in quella spazzatura sembra essere sempre corretta. Nota che questa soluzione funziona solo se il riferimento che stai usando corrisponde esattamente a un ramo che esiste su remoto (quindi i rami locali non funzioneranno).