2009-11-21 12 views
6

Il plugin git per hudson funziona bene. Tuttavia, lo script di build deve aggiornare un numero di versione nei file nel repository, eseguire il commit e tornare al repository.Polling infinito del ciclo Hudson per le modifiche nel repository Git?

Quando Hudson esegue il polling successivo per verificare le modifiche, entra in un ciclo infinito perché vede che il commit viene modificato come un "cambiamento", che impegna una modifica, quindi crea nuovamente, quindi commette un altro cambiamento, ecc. .. hai capito l'idea

mi si è fermato, gestiva un "git log" in ogni repository e confrontato le ultime commit ID sono esattamente la stessa cosa usando git ls-albero di testa

Inoltre, Hudson corre questo comando per verificare le modifiche:

git fetch + refs/teste/: refs/telecomandi/origine/ git ls-albero di testa

dal Hudson sé spinto il commit dalla repository di lavoro, ea quanto pare la partita risultati ls-albero, come può questo comando determina che c'è stato un cambiamento?

Sembra che debba memorizzare i risultati di ls-tree prima di eseguire la compilazione e confrontarsi con quello che non avrà l'ultimo commit. Ah. Posso provare a disattivare il commit per testare quella teoria.

In ogni caso, invece di risolvere qualsiasi problema nel plugin git Hudson, cosa posso fare per assicurarsi che alla fine della mia generazione che i pronti contro termine sono identici e che Hudson vedrà così.

Come risolvere il problema? Qualche idea?

Wayne

+0

Abbastanza sicuro. Quando il commit è commentato in modo che lo script spinga solo in alcuni repository, funziona correttamente. Cioè, Hudson riconosce che si sono verificati zero cambiamenti e attende cambiamenti senza loop. Così come fermare il ciclo infinito. Sembra che il plugin git per Hudson salvi lo stato repo dopo il recupero iniziale per la build. Ma sembra che dovrebbe salvare di nuovo lo stato del repository dopo una build di successo nel caso in cui la build abbia fatto un commit - o almeno lo abbia fornito come opzione. Qualsiasi organismo ha un'idea più facile e veloce per risolvere questo problema? – Wayne

+0

Oh, ho trovato un fork del plugin git-hudson su github dove qualcun altro sembra aver già aggiunto la gestione di questa situazione. Sto scaricando e costruendo e lo proverò. Ancora una volta se qualcuno ha una soluzione migliore, si prega di avvisare. Pubblicherò di nuovo se questo lo risolve. – Wayne

risposta

3

E la risposta è! ...

Il plugin Git Hudson era già biforcuta da qualcuno per aggiungere questa funzionalità funziona bene. Tuttavia, ho dovuto abbattere la fonte e correggere un paio di problemi minori.

Ora funziona magnificamente. La build si impegna e il plugin Git torna al repository senza eseguire il looping, pensando che sia di nuovo cambiato.

Meraviglioso!

Se qualcun altro ha bisogno di questo look per la forcella tickzoom dell'Hudson-GIT-Plugin su Github.com ma controlla se è già stato integrato nel progetto principale. Il committer ha dichiarato di essere interessato e di pianificare la combinazione delle forche.

Wayne

+0

Oh. questo è bello! Risulta che il plugin Hudson Git gestisce già questa situazione. Lo descrive sulla documentazione e mi è passato in testa qualche giorno fa. L'idea è di impegnarsi solo nei rami "feature". Quindi il server di build prima unisce il ramo di funzione a un ramo di integrazione e quindi funziona. In questo modo non è mai necessario che il server automatizzato abbia fusioni non veloci in avanti e che i commit avvengano nel ramo di integrazione nell'ordine corretto. Eccezionale. Devi amare il potere di Git. – Wayne

5

Il vostro sistema di generazione non dovrebbe avere alcuna interazione scrittura con il sistema di controllo di revisione. Sicuramente non dovrebbe spingere le modifiche automaticamente.

Il vostro sistema di compilazione può chiedere git (via git describe, per esempio) ciò che la versione attuale è. Qualsiasi altra cosa è ridondante e soggetta a errori.

Un'altra cosa che potresti considerare non è il polling delle modifiche. Sembra un modo stupido di operare. (Certamente, sono un utente di buildbot piuttosto abituato ad avere tutto attivato sugli eventi.)

Il repository git che viene interrogato sa quando cambia. Dovrebbe solo dire al sistema di CI di avviare immediatamente una build basata su questo. Prendi le tue build prima e dal momento che sono tutte attivate, non hai i computer seduti in giro a fare un sacco di lavoro senza una buona ragione.

+0

Sfortunatamente, la scrittura deve avvenire perché la build deve taggare la revisione con un numero di release come 0.5.6.135 e anche aggiornare i file di origine con il numero in modo che i file binari compilati abbiano la revisione. Ciò consente di rintracciare i bug al codice sorgente corretto. In precedenza abbiamo utilizzato SVN e tale plug-in ha un'opzione per "ignorare" determinati file durante il polling delle modifiche. Quindi abbiamo dovuto ignorare i nostri file di versione. Git è diverso, ovviamente. Se conosci qualche altro modo per realizzare lo stesso, fammi sapere per favore. – Wayne

+0

Mi piace la tua idea di non effettuare il polling delle modifiche in realtà. L'ostacolo ci sta anche evitando il loop infinito della spinta dalla build automatica. Quindi questo metodo deve anche avere un modo per confrontare tra loro. È complesso Quindi sondare e comparare sembra più semplice. E il polling ogni 1 minuto per le modifiche non è sicuramente un tipo di lavoro per un computer che si preoccupa di fare. – Wayne

+0

FYI, mi rendo conto ora perché dici che la build non dovrebbe mai scrivere nel repository. Ho tutto configurato e funzionante, ma la macchina di compilazione CI scrive e crea commit non-fastword quando lo fa alla fine della compilazione mentre i codificatori continuano a codificare e ad impegnarsi durante la compilazione. Requisiti complessi ma necessari. Pubblicherò un'altra domanda per affrontare questo. – Wayne