2011-10-13 7 views
16

Attualmente sto migliorando il processo di rilascio dei nostri progetti su Jenkins (1.430).Come configurare un singolo lavoro Jenkins per rendere il processo di rilascio dal trunk o dai rami?

lavori release corrente

Oggi, per un progetto specifico, abbiamo un lavoro dedicato al processo di rilascio. La procedura completa è la seguente:

  1. Lo sviluppatore che si occupa del rilascio cambia manualmente la versione di tutti i file pom.xml (in realtà utilizzando mvn versions:set -DnewVersion=2.0) per sbarazzarsi della -SNAPSHOT.
  2. Quindi, crea un tag in SVN (http://my-svn-repo/project/tags/V_2_0 per esempio).
  3. Una volta che questo tag è stato creato, accede al nostro server Jenkins e avvia una build di rilascio.
  4. Questa build gli chiederà quale tag desidera utilizzare per la build. Il lavoro è configurato come Configurazione parametrizzata, con il parametro Elenco tag di sottotensione.
  5. Jenkins quindi creerà le risorse da questo tag e le distribuirà nell'istanza Nexus.
  6. Una volta eseguita questa operazione, lo sviluppatore ha impostato le versioni pom.xml nella nuova versione di sviluppo (ad esempio 2.1-SNAPSHOT).

Il vantaggio di questo metodo è che ho solo un lavoro Jenkins, poiché la build si baserà solo su un tag.

Tuttavia, questa procedura comporta troppi interventi umani (modifiche di pom.xml, commit, tag, ecc.).

posti di lavoro nuova release

Ora, io uso il plugin Maven rilascio. Ho creato un lavoro che richiede tre informazioni per l'utente che lancia la compilazione:

  • la versione della release (parametro releaseVersion del plugin di rilascio);
  • la versione di sviluppo, dopo il rilascio (parametro developmentVersion del plugin di rilascio);
  • il nome del tag (parametro tag del plug-in di rilascio).

Questo lavoro funziona correttamente, ad eccezione di un punto: il lavoro si basa sul trunk o su un ramo in SVN. Ciò significa che se ho 2 rami (oltre al tronco), avrò bisogno di creare 3 lavori di rilascio: uno per ramo.

Un'idea per mantenere il meglio dei due mondi (vale a dire utilizzando la release di mvn, ma mantenendo 1 processo di rilascio) per aggiungere un parametro di build che chiederà all'utente il percorso del trunk/ramo. Quindi, anziché impostare http://my-svn-repo/project/trunk (o http://my-svn-repo/project/branches/BRANCH_V1) nella configurazione del lavoro, imposterò http://my-svn-repo/project/$FROM_BRANCH e chiederà all'utente di immettere il parametro FROM_BRANCH.

Il problema con questa soluzione è che l'utente dovrà immettere trunk o branches/BRANCH_Vx, il che potrebbe causare errori.

Idealmente, mi piacerebbe avere un parametro di compilazione che mi lascia la scelta del ramo (compresi tronco), come parametro tag Lista Subversion esistono per la scelta dei tag ...

Quindi il mio domanda: c'è un modo migliore per configurare il lavoro uno Jenkins che può funzionare su tutte le filiali?

Grazie.


Edit: Ho trovato il Jenkins plug Validating String che può essere interessante per assicurare che il valore definito dall'utente rispetta alcune espressioni regolari. Questo è utile nel mio caso ...

+0

è anche possibile utilizzare alcune modifiche della mia risposta qui: http://stackoverflow.com/a/41632406/2886891 –

risposta

9

È necessaria la versione 1.32 del plug-in subversion. Il issue JENKINS-10678 è stato implementato in quella versione.

Quindi si assegna solo l'URL del progetto (che deve contenere trunk, rami e tag) e offrirà il trunk insieme ai rami.

+0

Grazie! È quasi perfetto. Ora fornisce trunk, rami e tag. Vorrei rimuovere i tag, ma comunque è abbastanza buono ora. – romaintaz

+0

Il filtro "tag" ti può aiutare? –

+0

Non ho ancora provato, ma penso che possa essere d'aiuto, sì. – romaintaz

14

Solo per aggiungere alcune note alla risposta di Peter se non si ha familiarità con jenkins.

Il plug-in subversion viene installato di default nelle versioni recenti (come per settembre 2015).

Poi si dovrebbe configurare il progetto come segue:

  1. di controllo "Questa build è parametrizzato" (questo progettoviene parametrizzata in versioni più recenti)
  2. scegliere "tag Lista subverion (e più)"
  3. nel campo del nome, impostare un nome attendibile che può essere fatto riferimento più tardi nell'URL svn. Ho scelto svnbranch qui.
  4. nel campo URL del repository, dare il vostro URL del progetto (che deve contenere tronco, rami e tag)
  5. riempimento altro campo come le vostre esigenze
  6. nella gestione del codice sorgente, fare riferimento alla variabile definita prima nella vostra URL del repository.

controllo seguente screenshot:

enter image description here

enter image description here

+0

Il hook post-commit farà scattare questa build, se usiamo $ svnbranch? Solo curioso – user1164061