Quale server di integrazione continua è in grado di accodare i lavori?

Question

Caso di utilizzo:

Il server CI esegue il polling di alcuni repository VSC ed esegue la suite di test per ogni revisione. E se due o più revisioni sono state commesse, anche in un intervallo di tempo relativamente piccolo, voglio che il server CI inserisca ciascuna di esse in coda, esegua test per ciascuna, memorizzi i risultati e non esegua mai più test per quei commit. E non voglio che il server CI avvii i lavori in parallelo, per evitare problemi di prestazioni e arresti anomali in caso di molti lavori simultanei.

Quale server CI è in grado di gestirlo?

Il mio requisito aggiuntivo, meno importante, è che utilizzo Python ed è consigliabile utilizzare software scritto in Python, quindi ho esaminato il progetto Buildbot, e in particolare voglio vedere le recensioni per questo strumento in questione utilizzabile in generale ed è in grado di sostituire le soluzioni più diffuse come Travis o Jenkins.

Answer 1

Quanto Buildbot e pitone, è possibile coordinare parallelo costruisce da configurazione, ad esempio:

modellazione processi paralleli: I passaggi

svn up 
configure 
make 
make test 
make dist 

Inoltre, è anche possibile provare a utilizzare un Triggerable scheduler per il tuo costruttore che esegue i passaggi U, V, W.

Dal docs:

Lo scheduler triggerable attende di essere innescato da una fase di trigger (vedi Attivazione Scheduler) in un altro build. Questo passaggio può facoltativamente attendere per completare le build dello scheduler. Ciò fornisce due vantaggi su scheduler dipendenti.

Riferimenti:

• how to lock steps in buildbot
• Coordinating Parallel Builds with Buildbot

Answer 2

Non voglio quel server CI sarebbe avviare i lavori in parallelo per evitare problemi di prestazioni e crash in caso di molti lavori simultanei.

In buildbot è possibile limitare il numero di posti di lavoro in esecuzione in un unguento con max_build parametro o locks

Answer 3

ho usato Jenkins per fare questo. (con sovversione principalmente, c/C++ build e anche lavori scripts bash/python)

La gestione più semplice e predefinita delle modifiche VCS/SCM in jenkins è il polling delle modifiche in un tempo prestabilito. Una build viene attivata se c'è qualche cambiamento. Più di un commit può essere incluso in build (ad es. Se 2 commit sono fatti vicini) quando si usa questo metodo. Jenkins mostra i collegamenti all'aggiornamento scm e scm, oltre a mostrare i log di build e puoi facilmente configurare gli output di build e la presentazione dei risultati del test.

https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project#Buildingasoftwareproject-Buildsbysourcechanges

Che VCS/SCM stai usando? interfacce Jenkins per un buon paio di VCS/SCM: https://wiki.jenkins-ci.org/display/JENKINS/Plugins#Plugins-Sourcecodemanagement

Questa domanda risponde come fare Jenkins costruire su ogni sovversione commit: Jenkins CI: How to trigger builds on SVN commit

Answer 4

TeamCity è libero (fino ad un certo numero di generazioni e costruire agenti) e ricco di funzionalità. È molto facile da installare e configurare, anche se potrebbe richiedere del tempo per trovare la strada attraverso la ricchezza di opzioni. È estremamente ben documentato: http://www.jetbrains.com/teamcity/documentation/

È scritto in Java ma supporta molti strumenti in modo nativo e altri tramite l'esecuzione da linea di comando, quindi è possibile creare qualsiasi cosa con esso che si desidera. (Lo uso principalmente per Ruby.) It understands the output of many testing tools; se non stai usando uno di loro forse il tuo può emulare il loro output. It's quite extensible; it has a REST API and a plugin API.

Può essere configurato per costruire su ogni commit, o per costruire tutti i commit che sono arrivati ​​in un determinato periodo di tempo, o per innescare in altri modi. Docs here: http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers

Per impostazione predefinita, avvia un singolo build agent ed esegue una build alla volta su quell'agente di build. Puoi eseguire più build agent per la velocità. Se non si desidera eseguire più di una build su una macchina, avviare solo un build agent su ogni macchina.

Answer 5

C'è un plug-in Concorrent Builds Throttle per Jenkins e Hudson. Ti consente di specificare il numero di build simultanee per lavoro. Questo è quello che dice sulla pagina dei plugin:

Va notato che Jenkins, per impostazione predefinita, non esegue lo stesso lavoro in parallelo, in modo da non dovete realmente acceleratore nulla se si va con il default. Tuttavia, v'è l'opzione Esegui concomitante costruisce, se necessario, che consente di eseguire lo stesso lavoro a tempo multiple in parallelo, e, naturalmente, se si utilizzano le categorie di seguito, sarà anche in grado di limitare i lavori multipli.)

Esiste anche Gitlab CI, un bellissimo progetto Ruby moderno che utilizza corridori per distribuire build in modo da poter, credo, limitare il numero di corridori a 1 per ottenere l'effetto desiderato. È strettamente integrato con Gitlab, quindi non so quanto sarebbe difficile usarlo come servizio indipendente.

www.gitlab.com

www.gitlab.com/gitlab-ci

Per solo test eseguito una volta per ogni revisione si può fare qualcosa di simile:

1. accumulo
2. post-generazione
   • di controllo se la revisione della build è in/tmp/Jenkins-test-run
   • se la revisione è nel file saltare i test
   • se la revisione è NON nella corsa di file tests
   • se abbiamo eseguito i test quindi scrivere l'ID in/tmp/Jenkins-test-run