<div dir="ltr">Hi,<div><br></div><div>While trying to understand how our gerrit+jenkins setup works, I realized of a possibility of allowing bugs to get in.</div><div><br></div><div>Currently, our gerrit is setup to have cherry-pick as the submit type. Now consider a case where:</div><div><br></div><div>Dev1 sends a commit B with parent commit A(A is already merged).</div><div>Dev2 sends a commit C with parent commit A(A is already merged).<br></div><div><br></div><div>Both the patches get +2 from Jenkins.</div><div><br></div><div>Maintainer merges commit B from Dev1.</div><div>Another maintainer merges commit C from Dev2.</div><div><br></div><div>If the two commits B and C changed code which had no merge conflicts but were conflicting in logic,</div><div>then we have a master which has bugs.</div><div><br></div><div>If Dev3 now sends a commit D with re-based master as parent, we have the following cases:</div><div><br></div><div>1. If bug introduced above is not racy, we have tests always failing for Dev3 on commit D. Tests that fail would be from components that commit B and C changed. Dev3 has no idea on how to fix them and has to enlist help from Dev1 and Dev2.</div><div><br></div><div>2. If bug introduced above is racy, then there is a probability that Dev3 escapes from this trouble and someone else will bear it later. Even if the racy code is hit and test fails, Dev3 will probably re-trigger the tests given that they failed for a component which is not related to his/her code and the bug stays in code longer.</div><div><br></div><div>The most obvious but not practical solution to the above problem is to change the submit type in gerrit to &quot;fast-forward only&quot;. It would then ensure that once commit B is merged, Dev2 has to re-base and re-run the tests on commit C with commit B as parent, before it could be merged. It is not practical because it will cause all patches in review to get re-based and re-triggered whenever a patch is merged.<br></div><div><br></div><div>A little modification to the above solution would be to </div><div><ul><li>change submit type to fast-forward only<br></li><li>don&#39;t run any jenkins job on patches till they get +2 from reviewers</li><li>once a +2 is given, run jenkins job on patch and automatically submit it if test passes.</li><li>automatically rebase all patches on review with new master and mark conflict if merge conflict arises.</li></ul><div>As a side effect of this, Dev would now be forced to run a complete regression on dev machine before sending a patch for review.</div><div><br></div><div>Any thoughts on the above solutions or other suggestions?</div></div><div><br></div><div>Thanks,</div><div>Raghavendra Talur</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>