2012-01-04 11 views
5

Ho diversi lavori in Jenkins, suddivisi in progetti con le loro "pipeline" di build/test/analisi. La maggior parte di questi lavori sono in realtà comandi remoti invece di build on-box.Code di compilazione multiple in Jenkins

Tuttavia, Jenkins pronto per l'uso supporta solo una coda per tutte le build. Voglio definire una coda per progetto (o vista).

Come potrei realizzare questo?

risposta

4

Per quanto ne so, questo non è possibile senza modificare il codice Jenkins, ma penso che si possa raggiungere lo stesso obiettivo con una manutenzione minima usando build slaves. Diverse build possono essere eseguite contemporaneamente sugli slave o anche sullo stesso slave se si definire più esecutori (se la macchina slave ha> 1 CPU). Puoi etichettare gli schiavi per controllare quali lavori vengono eseguiti su ciascuno di essi, in modo da poter disporre di un set separato di slave per ciascuna delle tue pipeline.

Oltre al sovraccarico per assicurarsi che le macchine slave di base rimangano in funzione, l'overhead specifico Jenkins per il funzionamento di uno slave è minimo. È possibile utilizzare un processo sul master per mantenere aggiornato il file JAR dello slave e gli strumenti di compilazione; nel mio negozio utilizziamo un semplice script rsync che viene eseguito ogni volta che il master o lo slave viene riavviato per copiare gli ultimi strumenti dal master allo slave e riavviare il processo slave.

Questo approccio riduce anche la misura in cui il master Jenkins è un singolo punto di errore.

+0

No. Sto chiedendo la possibilità di avere più * code *. Posso aumentare il numero di lavori simultanei in una coda. –

+0

Puoi spiegare perché hai bisogno di più code? –

+0

Ho più progetti. Ogni progetto ha la propria pipeline. Ogni progetto può essere realizzato in concomitanza con gli altri, fino ad un certo limite X, ad esempio limitato dalle licenze per i suoi strumenti. Una build può essere avviata localmente (raro) o remotamente (comune). Idealmente, Jenkins non viene installato su ogni macchina di costruzione (il costo amministrativo è molto alto) - c'è un dispatcher centrale che invia comandi ai compilatori remoti. –

0

Ciò che si desidera è possibile solo eseguendo un master Jenkins separato per ogni progetto.

Di solito le persone pensano che un master Jenkins abbia un sovraccarico amministrativo maggiore rispetto a uno schiavo, ma se ciò non vale per te, puoi eseguire più master su un server, assegnandogli solo porte differenti.

Se questo non ti fa bene, allora forse Jenkins non è lo strumento giusto per te. Non è l'unico server CI esistente. Jenkins è molto facile da configurare, ma d'altra parte non è possibile fare una profonda personalizzazione, come più code di costruzione.

0

So che questo thread è vecchio, ma ho pensato di commentare comunque.

IMO

vorrei usare un master e più slave. Ma gestiamo i requisiti di configurazione dello strumento tramite uno strumento di gestione della configurazione o CMT (Chef, Puppet, Ansible, Etc.). Vorrei bloccare le pipeline a specifici build slave tramite tag per requisiti specifici (windows, linux, Mac, visualstudio, maven, android-sdk, ecc.). Dal momento che gli slave sono configurati nel tuo cmt puoi semplicemente far ruotare una nuova macchina molto facilmente, indipendentemente dal fatto che si tratti di una VM o di un hardware fisico. Un maestro Jenkins può gestire più di 200 schiavi costruiti.

0

Prima di tutto, vorrei sottolineare che, come altre risposte descrivono, pegging le diverse code di build a diversi slave sarebbe la soluzione consigliata, tuttavia c'è un modo per ottenere lo stesso effetto con il solo nodo master .

C'è un plugin chiamato Throttle Concurrent Builds. Consente di impostare il livello di concorrenza di build in base al singolo lavoro o in tutti i processi.

La documentazione è stata un po 'vago, quindi questi sono i passi che hanno lavorato per me:

  1. Dopo aver installato il plugin, andare a Gestire Jenkins ->Configure System.
  2. Nella sezione Throttle Concurrent Builds definire i gruppi di lavori e i rispettivi livelli di concorrenza.
  3. Ora, per ogni lavoro che si desidera applicare la regolazione, andare alla sua configurazione, abilitare Throttle Concurrent Builds (generale sezione), selezionare Throttle questo progetto come parte di una o più categorie, e assegnare uno o più dei le categorie definite nel passaggio precedente (non è necessario impostare nuovamente i limiti qui).
Problemi correlati