¿Cómo prevenir construcciones rotas en master usando gerrit?

El flujo de trabajo de Gerrit se inventó para hacer que las construcciones pasaran antes de que la falla se introdujera en el maestro. Esto evita la mayoría de las fallas, pero el maestro aún puede romperse.

Considera esto:

  • Dev A presenta una característica 1 con una testing y la fusiona
  • Dev B introduce una característica 2 que es incompatible con la característica 1, pero lo hace de modo que no hay conflictos de combinación => fusionados
  • Dev C descubre que la compilation maestra está rota.

¿Cómo prevenir que esto suceda?

aquí hay una línea de time:

master .-> feature 1 with a test1 => build passing .-> feature 2 that causes test1 to fail => build passing because there is no dependency on feature 1 | <-. merge feature 1 <-. merge feature 2 => no conflicts . master is broken 

Ejemplo

código antes de la function 1 y la function 2:

 # file: code.js function code() { return true; } 

testing agregada en la característica 1:

 # file: test_code.js function test_code() { assert(test_code() == true); } 

testing agregada en la característica 2:

 # file: test_feature.js function test_feature() { assert(test_code() == false); } 

código cambiado en la característica 2:

 # file: code.js function code() { return false; } 

Como ve, no hay conflictos.

Si Dev B está haciendo la fusión. Es su responsabilidad ejecutar las testings y asegurarse de que aún pasen.

Cuando utilizo un flujo de trabajo clásico de Gerrit (es decir, Gerrit haciendo la fusión), estoy bastante seguro de que Gerrit le pedirá que vuelva a calcular su cambio antes de fusionarlo; Todo lo que recuerdo de esa situación es cuando hay un conflicto, entonces estoy obligado a ejecutar la rebase localmente, pero en ese caso si las testings fallan y de alguna manera me olvido de ejecutarlas, Jenkins lo recoge y ejecuta las testings. en mi cambio rebase e inmediatamente marque mi CL con un -1 (verificado).