2012-12-07 13 views
7

Due sviluppatori stanno lavorando sul ramo di sviluppo su due modifiche completamente diverse (ad esempio, due file diversi). Entrambi inviano il loro lavoro allo stesso tempo, attivando due build Jenkins. Queste build vanno bene ma una recensione richiede più tempo dell'altra.In Gerrit, come posso evitare che un set di patch venga inviato che non è completamente aggiornato?

Il primo dev valere il loro set di patch e non ci sono commit intermedi sviluppare in modo Gerrit si fonde proprio nel.

Il secondo dev poi sottopone il loro set di patch. Anche se ora c'è un commit intermedio, l'unione stessa è banale e Gerrit esegue l'unione.

Ora abbiamo due build, nessuno dei quali contiene il lavoro dell'altro.

Vorrei bloccare la seconda sottomissione se ci sono commit intermedi, anche se l'unione sarebbe totalmente banale, causando invece lo sviluppatore rebase e aggiorna la loro sottomissione (e innescare una nuova build in Jenkins nel processo).

Cosa faccio a impostare in Gerrit per bloccare tali fusioni banali, ma non volute quando una revisione è completa, il set di patch viene inviato ma il ramo di destinazione ha una fusione intermedia su di esso?

risposta

6

È possibile modificare le opzioni di progetto in Gerrit Per avanzare velocemente solo, ciò impedirebbe il cambiamento di andare in quanto non è un fast forward merge. Quindi forzare lo sviluppatore2 a lanciare pull --rebase e premere nuovamente, ora la modifica che ha fatto lo sviluppatore1 sarà parte della verifica.

+0

Ciò causerà altri effetti collaterali? – MartyMacGyver

+1

L'effetto collaterale è che gli sviluppatori hanno bisogno di tirare --rebase prima di premere per la revisione –

+1

Quindi non ci sono effetti collaterali indesiderati. Apprezzo la tua risposta e apprezzerei un upvote qui (penso che questa domanda sarà utile per gli altri). Grazie ancora! – MartyMacGyver

Problemi correlati