Sto tentando di implementare un flusso di lavoro Integration Manager modificato simile a quello descritto in ProGit.Integration-Manager Git Flusso di lavoro con Jenkins/Hudson
Invece di un integration manager eseguire le unioni, voglio sviluppatori di fondere localmente prima di pubblicare il loro codice, e voglio un Quality Gateway che impone i nostri standard di integrazione continui, come ad esempio un livello minimo di copertura del codice e 100 % passa il test, prima di consentire al codice di accedere al repository benedetto per essere verificato da altri sviluppatori. L'idea è che il codice nel repository benedetto rispetti sempre lo standard minimo che definiamo e costruisce sempre.
Desidero che Jenkins esegua il ruolo del gateway di qualità, inserendo il codice nel repository benedetto solo quando le build hanno esito positivo.
Finora, ho impostato il sistema in modo tale che ci siano i seguenti repository pubblici: il repository benedetto, un repository sul server di build per Jenkins, che è un repository scoperto accessibile tramite gitosis, e naturalmente i repository dello sviluppatore .
Ho sviluppatori che estrapolano il benedetto repo e spingono al repo di integrazione. Ora sto cercando di convincere Jenkins a spingere le build di successo dal repo di integrazione al repo benedetto.
Finora, l'unica opzione che ho visto sembra simile a quello che sto cercando di ottenere è l'opzione "Push Only If Build Succeeds" nelle impostazioni di Git Publisher delle azioni di generazione post nella configurazione del progetto di Jenkins. Tuttavia, tali opzioni non consentono di specificare l'url push o il remoto da inviare.
A quanto mi risulta, le impostazioni di Git Publisher spingono i cloni di Jenkins nel repository pubblico di Jenkins, ma voglio passare a un altro telecomando, il repository benedetto.
Qualcuno ha qualche suggerimento su come posso convincere Jenkins a spingere al repo benedetto?
EDIT 0: Ho provato a mettere una fase di post per eseguire il comando spinta al mio repository benedetta. Questo sembra funzionare, in quanto non ci sono errori. Tuttavia nessun cambiamento sono spinti ei registri mostrano che git pensa che tutto sia aggiornato:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 7 seconds
[INFO] Finished at: Fri Nov 18 16:10:50 UTC 2011
[INFO] Final Memory: 19M/45M
[INFO] ------------------------------------------------------------------------
channel stopped
[My Project] $ /bin/sh -xe /tmp/hudson5604254372179801803.sh + git push [email protected]:my-project.git --all
Everything up-to-date
Non so perché git pensa che ci sia nulla da spingere, perché non v'è dubbio.
Sembra interessante, ma l'unica cosa che aggiunge che il nostro processo attuale non ha è un processo di revisione formalizzato. I nostri progetti sono mavenised, quindi se passano la build sappiamo che superano i test e altri requisiti che abbiamo definito.Non sembra aggiungere abbastanza (al nostro processo) per giustificare che un altro strumento complichi il nostro ambiente. Terrò in mente man mano che cambiano le nostre esigenze, grazie! – chrisbunney
Capisco la necessità di limitare la complessità :-) Voglio solo dire che aggiunge sia la recensione che riporta i risultati del test CI/Test su ogni cambiamento prima che venga commesso al tuo repo benedetto. –
Sì, sarà bello quando arriveremo a quella fase :) – chrisbunney