Jenkins Costruzione parziale/Configurazione modulare su gancio di commit

Question

Strumenti:
Jenkins ver. 1.470
Maven 2
Subversion

Ambiente

assumere la mia generazione ha una serie di progetti di A-D. Il grafico delle dipendenze esiste come mostrato. Vale a dire: B dipende dalle classi in A, C dipende dalle classi in B, D dipende dalle classi in A. Creiamo le build jenkins in modo tale che chiamino le build dipendenti da esse come un'azione post-build.

Un
| -> B -> C
| -> D

Ogni sera, abbiamo innescare una generazione completa di Jenkins (A costruisce, innesca B (trigger C), D innesca). Questo viene fatto abbastanza facilmente dicendo a A di costruire di notte, e il resto a cascata.

Problema

Tuttavia, su una impegniamo vogliamo costruire i progetti che sono stati commessi a una volta.

• Situazione 1: Abbiamo Poll il repository (o utilizzare commit hooks, non fa differenza) e scoprire che c'era un commit a B, allora B costruirà e C costruirà. Successo!

• Situazione 2: Noi interrogare il repository e scopriamo che B e C sono stati impegnati a in un commit, quindi Jenkins cercherà di costruire B (innescando una build di C), e costruire C (una seconda generazione). Errore. Vedi cosa succede? C è stato costruito due volte, prendendo tempo prezioso per la costruzione. Mantieni veloce la costruzione!

Qualcuno sa un modo per attivare solo la più alta progetto in ogni cantiere di costruzione impegnati?

immagino una soluzione potrebbe essere un gancio SVN complessa che determina la massima progetto in ciascuna condotta ...

• Situazione 3: Impegnarsi a B C e D in un commit. Il gancio SVN trova C dipende da B. L'hook richiama collegamenti specifici del progetto per avviare build per B e D.

Insidie: hook di commit SVN molto complesso. Devono mantenere la conduttura nel gancio SVN.

Mi sembra che questo sia un problema in cui altri si sono imbattuti. C'è un plugin Jenkins che aiuta con questo?

Answer 1

Sarebbe un'idea dire che jenkins attenda con la compilazione fino a quando una costruzione che c dipende da è finita. È una bandiera all'interno della configurazione del lavoro per farlo. Ma devi farlo per ogni lavoro. Btw ...c'è anche un'altra bandiera che richiede a jenkins di aspettare con la build fino a quando un lavoro dipendente non è finito.

Answer 2

Sto anche cercando una soluzione efficiente a questo problema. Ho visto diversi suggerimenti, ma finora siamo riusciti a evitare una delle insidie ​​serializzando la build utilizzando il plugin Locks & Latch. Non impedisce a un progetto di creare più volte da un singolo check-in, ma garantisce che il progetto venga ricostruito sequenzialmente dopo il completamento del progetto upstream.

In realtà è un problema complesso da risolvere, ma ho pensato di scrivere un plug-in per risolvere il problema. Una soluzione semplice è solo per verificare se un progetto upstream è attualmente in costruzione e rimuoverti dalla coda di build, se è così. Dal momento che il lavoro upstream darà il via alla tua build una volta completata, questa è un'opzione.

Un'opzione migliore sarebbe un plug-in che gestisce automaticamente la coda di build in base al grafico delle dipendenze. Questo può essere complicato, perché è necessario assicurarsi che nessuna generazione abbia inizio finché tutte le sue dipendenze non sono state completate. Essenzialmente questo significa che ogni checkin farà sì che il plugin aggiunga automaticamente tutti i build downstream alla coda in modo che possa gestirli. È possibile che esista un modo intelligente e più semplice per farlo accadere con i trigger esistenti a monte/a valle, ma non è ancora chiaro per me come farlo accadere. Esistono già plug-in di pipeline di build che pretendono di gestire questa situazione, ma chiaramente non fanno nulla per impedire la condizione di competizione in cui una build downstream può essere attivata dallo stesso checkin di una build upstream.