I caused this. 

So, I broke this in  issue 622148 : "Gerrit CQ should abort the run if there is merge conflict."

So, again, the rational was to bring CQ in line with Chromium CQ, in which patches are actually rebased. In this case, if patch has a merge conflict, there is no point in trying -> it'd fail.

Chromium recipe doesn't yet rebase patches of Gerrit, but will soon, andybons@ is working on that in  issue 612417 ).

Angle is actually re-using chromium trybot recipe. As such, I am not sure what to do. I see these ways out:

1. Basically, WontFix this and do what CQ says and rebase first, then re-try.
2. Allow Angle CQ to work as before:
  * add cq.cfg option to avoid checking if CL can be "merged", essentially undoing  issue 622148 
  * modify chromium_trybot to support Angle's use-case. Makes chromium_trybot recipe ever more complicated, and importantly makes trybots "green" even if they actually break chromium at HEAD.

3. Where I want to be eventually: hybrid. Provide two kinds of tryjobs:
 3.1 those ran at *exactly* the revision specified in patch (ie no rebase).
 3.2 those ran with rebase, which is what CQ should do because that's important to avoid breaking HEAD as much as possible. These runs should be rejected by CQ if Gerrit says there is merge conflict.


In other words, up until ~2 weeks ago, Gerrit (CQ + bot_update) did 3.1. Chromium CQ has been at 3.2.


I don't have a strong preference short term, but long term I really want to be in #3.

Is there a pressing need for this change immediately? Maybe we could restore the previous functionality in the interm while we work on a solution. It is pretty important for us to be able to test all the patches in a patch series. Maybe other folks on the cc list could contribute more productive ideas, but at the moment I'd like to avoid solution #1.

Hm, the new behavior isn't breaking patch dependencies. TO illustrate:

A -> B -> C = master
 \
  X  = change1
    \
      Y = change2


and suppose you trigger CQ on change2.

In 3.1, tryjob would checkout exactly Y, which will necessarily contain X as it's parent.

In 3.2, tryjob would checkout Y (hence also X) and then rebase it onto current head (C). The resulting state of cehckout is not exactly Y, but it'd still contain Y and X changes in it.

So, IMO, if all you want is having all dependencies correctly checked, then we aren't breaking you.

tl;dr I'm reverting what I did in  issue 622148 , and merge this as a dup to that issue.

ok, i figured it all out: change Y above will be considered as unmergable by Gerrit because X hasn't landed yet. Therefore, CQ would never run on Y. And that's teh problem for not just Angle but for everybody else!

At the same time, as I discussed with Jamie in GVC, Angle isn't against actually rebasing patches.

I've deployed older CQ version. Sorry for breakage and thank you very much for reporting.

No problem, thanks for figuring this out and fixing it for us.