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:
¿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).