Perché Jenkins ti avvisa se gli dici di controllare le modifiche ogni minuto?

Ci sono due cose qui: il client (in questo caso Jenkins) e il server (svn o git o qualcos'altro).

Poiché il cliente, chiedendo ogni minuto può consumare un po 'di risorse - rete e disco sul server, per non parlare delle proprie build interne che competono con le risorse locali per controllare se qualcosa è stato aggiornato.

Sul lato server, una mezza dozzina di progetti che vengono interrogati ogni minuto può anche consumare risorse (disco e rete) e può iniziare a contendersi con altri aggiornamenti client (come i tuoi sviluppatori).

Il fatto è che se vuoi iniziare la costruzione il prima possibile, ci sono altre opzioni per questo. Puoi fare una spinta invece di un tiro. Ad esempio, su Stack Overflow: Jenkins CI: Come attivare i build sul commit SVN e Come configurare Git post commit hook in cui l'azione di spingere un commit sul server attiverà una build di Jenkins. Non avrà mai bisogno di eseguire il polling (molto meno ogni minuto) per vedere se ha bisogno di costruire perché il server gli dice di farlo quando è necessario.

Come follup di tutto questo, suggerirei di leggere Il sondaggio deve morire: l'attivazione di Jenkins si basa su un git hook che prende una versione più ponderata del problema.

Uno dovrebbe esaminare il motivo alla base del desiderio di avere il polling del server ogni minuto. Questo è ciò che Jenkins, in parte, cerca di affrontare con l'avvertimento. Se vuoi "costruire non appena si verifica un commit", i ganci sono la migliore tecnologia da utilizzare sia per il build server che per l'origine dei dati.

D'altro canto, su molti progetti, un ritardo su una build non è un grosso problema, perché un ritardo di pochi minuti lo renderebbe evidente. In molti dei progetti su cui ho lavorato a un test completo e all'analisi (come fatto sul server CI perché ci è voluto troppo tempo per essere eseguito sulla macchina di uno sviluppatore) sono trascorsi 10-15 minuti il build server non veniva tassato con altre build al momento ( tutti i test unitari e l'analisi del codice statico su un progetto SLOC di 1,5 M, quindi attivare un'istanza di HSQLDB e jetty ed eseguire un'altra serie di test ...). Fare il sondaggio ogni mezz'ora era più che sufficiente (e se uno sviluppatore voleva che la build iniziasse ora in modo che fosse fatta prima che lui o lei volesse andare a pranzo o partire per il giorno e sapere con certezza che non avrebbero subito l'ira di una build distrutta al ritorno ... beh, c'è sempre il pulsante "build now")

Non sono sicuro che l'argomento delle risorse di polling sia convincente. È un'operazione relativamente efficiente sulla maggior parte dei sistemi di controllo delle versioni, specialmente se stai solo controllando e non ancora scaricando le modifiche. Anche se, una notifica push è certamente preferibile.

Di solito sono le risorse di costruzione ad essere il fattore limitante, a seconda della frequenza con cui si verificano i commit e da quanto tempo impiegano le build. Se si avvia una compilazione troppo frequentemente e i nodi di generazione sono al massimo, ciò può aumentare la latenza media per ottenere risultati, specialmente nei momenti di punta. Inoltre, ciò che può accadere è che un commit interrompe la compilazione, ma quando si ottengono i risultati, si hanno diverse build successive interrotte dallo stesso bug. Ciò condiziona gli sviluppatori a prestare meno attenzione al server CI.

Quindi se ti capita di avere build veloci e i tuoi nodi di costruzione non vanno mai al massimo, aumenta in ogni caso la frequenza di polling. Se i nodi di costruzione sono sempre al massimo e si impegna a interrompere sempre 3 o 4 build prima ancora di conoscerli, è possibile ridurre la frequenza di polling.