2009-12-09 16 views
13

Come dice il titolo, sto cercando di ottenere un lavoro di rilascio automatico su Hudson. È un progetto Maven e tutto il codice è in Git. Manualmente, faccio l'uscita sulla mia macchina personale in questo modo:Impossibile ottenere il rilascio automatico lavorando con Hudson + Git + Maven Release Plugin

git checkout master 
mvn -B release:prepare release:perform 

Questo funziona perfettamente. Il plug-in di rilascio di Maven spinge correttamente il tag di rilascio nel repository di origine e il successivo commit che esegue il dump della versione sul successivo SNAPSHOT.

Tuttavia, quando eseguo lo stesso lavoro Maven tramite Hudson (sia creando il mio lavoro di "rilascio" o utilizzando lo M2 Release Plugin) non funziona così bene. Il tag di rilascio viene inviato al repository di origine e il rilascio viene trasferito al repository Nexus, ma il successivo commit che esegue il dump della versione sul successivo SNAPSHOT non viene eseguito. Inoltre, il ramo "master" nel repository di origine non viene affatto modificato. Tuttavia, ho cercato nell'area di lavoro di Hudson per il lavoro e la versione è stata aggiornata.

Dopo aver esaminato l'output del lavoro Hudson, sembra che il plug-in Git non esegua effettivamente il checkout "master", ma piuttosto l'ID SHA1. Cioè, se i punti di etichetta ramo "master" di commettere "f6af76f541f1a1719e9835cdb46a183095af6861", Hudson fa

git checkout -f f6af76f541f1a1719e9835cdb46a183095af6861 

invece di

git checkout -f master 

Di conseguenza, i cambiamenti che il plugin di rilascio Maven sta facendo non sono in realtà su qualsiasi ramo (certamente non su "master") e queste modifiche non arrivano al repository di origine. Funziona con il codice giusto, ma in termini di contabilità, le modifiche sembrano andare perse perché nessuna etichetta di ramo punta a loro.

Qualcuno ha ottenuto che la combinazione Hudson + Git + Maven Release Plugin funzioni correttamente? C'è qualche configurazione aggiuntiva da qualche parte che posso impostare per fare in modo che questo accada? O è un bug nel plugin Hudson Git?

Grazie in anticipo.

+0

Sembra che lo stesso problema sia menzionato in [Jenkins maillist] (http://jenkins.361315.n4.nabble.com/Maven-release-plugin-Git-td2317181.html), in [Hudson maillist] (http://java.net/projects/hudson/lists/users/archive/2011-08/message/135), in JIRA [HUDSON-5856] (http://issues.hudson-ci.org/browse/HUDSON -5856), in [GitHub gist] (https://gist.github.com/1351153). Anche [la spiegazione sul TESTO distaccato] (http://stackoverflow.com/a/5772882/267197) è relativa. –

risposta

3

Dopo aver manipolato un po 'di più le cose, ho provato a impostare il mio rilascio automatico come lavoro autonomo (ad esempio, non utilizzando il plugin M2 Release). Invece di avere il lavoro impostato per "costruire un progetto maven2", ho realizzato un lavoro "Costruisci un progetto software libero". La prima cosa che fa è eseguire un comando di shell:

git checkout master 

Il passo successivo è un'invocazione Maven, configurato nel seguente modo:

-e -B release:prepare release:perform 

Questo primo comando shell è la chiave; ora che sono effettivamente su un ramo, tutte le modifiche eseguite dal plug-in di rilascio vengono reindirizzate al repository di origine.

Mentre questo tecnicamente risponde alla mia domanda, sono ancora curioso delle esperienze degli altri con questa combinazione di plugin Hudson + Git + Maven Release.

Grazie

+0

Ecco un'altra recente esperienza di Git-Hudson: http://blog.javabien.net/2009/12/01/serverless-ci-with-git/ – VonC

+0

Anche io sto riscontrando questo problema, ma non credo questa è davvero una soluzione - non funzionerebbe non appena si hanno più di un ramo attivo. Inoltre, dover ricorrere a un progetto a mano libera non è l'ideale. – cemerick

+0

Grazie per questo. Ho passato ore a cercare di capire come ottenere Hudson (v. 3.3.2) per fare una build di rilascio sul ramo master usando il plugin Hudson Maven3 (v. 3.0.5) senza alcun risultato. – sdoca

5

A cura di eliminare di informazioni aggiornate.

Vedere this answer per la soluzione corrente (non compromessa).

+0

Sei sicuro che questo è stato risolto in 0.8? Sto sperimentando questo aspetto e sto ancora vedendo questo genere di cose: [spazio di lavoro] $ git checkout -f 2904dc ... Hudson sta controllando lo SHA-1 piuttosto che il riferimento, lasciando il TEST distaccato . Questo mi dà fastidio perché il mio script di build deve sapere su quale ramo si sta costruendo, e il parametro 'branch to build' non viene esportato in una variabile di ambiente, quindi non c'è modo di sapere. – meowsqueak

0

@meowsqueak: ho avuto lo stesso problema e ho corretto il plugin per aggiungere una variabile chiamata "GIT_BRANCH" all'ambiente di sviluppo. Se vuoi provarlo, il plugin modificato è disponibile per il download @github: http://github.com/jberkel/Hudson-GIT-plugin/downloads. Ho anche contattato l'autore upstream per fartelo integrare nella linea principale. Ovviamente questo non risolve il problema del CAP distaccato, ma almeno gli script di costruzione sanno in quale ramo ci si trova.

2

Se ho capito bene, questo comportamento è intenzionale perché Nigel non crede che Maven dovrebbe impegnarsi al SCM. C'è una soluzione relativamente indolore (anche se sarebbe meglio non dover lavorare su qualcosa). Io uso i passaggi aggiuntivi Hudson M2 plug-in e fare una fase di pre-accumulo:

git checkout master || git checkout -b master 

git reset --hard origin/master 

Questo viene eseguito dopo git abbia controllato l'SHA-1, ma prima di Maven inizia la costruzione. Facendolo in questo modo mi permette di impostare il master su qualunque cosa il plugin git abbia estratto. Quindi utilizzo il plugin maven-release-per eseguire i rilasci e le modifiche e l'implementazione SCM funzionano correttamente.

+0

Chi è Nigel? L'autore del plugin git per Jenkins? –

0

So che è una vecchia domanda, ma ancora una buona risposta. Fai ciò che viene suggerito qui: https://blogs.adobe.com/jzitting/maven-release-builds-with-jenkins-and-git/ "La soluzione era impostare l'opzione" Checkout/unisci al ramo locale (facoltativo) "nelle impostazioni Git avanzate nella schermata di configurazione build di Jenkins." Ho messo lì "HEAD" e so rilasciando i lavori.

Problemi correlati