Hi please change integration/config can merge to merge instead of fast-forwarding it would be easer and wont need to rebase everytime someone merges something at the same time as another patch merging.
See @hashar comment below T111426#1605970
Should probably be documented somewhere on the wiki or even better in Zuul upstream documentation.
No but when merging two patch at the same time only the first submitted patch will merge the second one will say rebase first before merging.
Please see https://gerrit.wikimedia.org/r/#/c/235783/ which was merged at the same time as the one that i uploaded was merged.
It is important that patches are rebased properly for when people run jenkins-job-builder locally since the YAML files depend upon each other and can overwrite other patches.
Plus it keeps git log much cleaner.
So that is actually a bug in Zuul when a repository is fast forward only. A change behind in the queue should be kept on hold cause it can only be merged if all changes ahead failed. Else if a change ahead is merged, the change can no more merge because of fast forward only.
Given two changes A, B based on the tip of the branch 'master' at commit TIP. One does:
CR + 2 Change A (parent TIP) CR + 2 Change B (parent TIP).
Gerrit reports that each of those changes can be merged since they are each a fast forward from the tip of the branch. So Zuul process them (since they can be merged) and in the dependent pipeline gate-and-submit
A B
The set of jobs are being tested as:
| For A | Commit of A |
| For B | Commit of A + Commit of B |
Once the jobs of A are completed, Zuul submit the change in Gerrit and the tip of the branch master is now A:
* (master) Change A | | * Change B |/ * TIP
The B jobs have been tested as if A has been merged, which is Zuul usual behavior, then it attempts to submit B, Gerrit reject the change because the parent (TIP) is not the tip (now A).
The way Zuul could fix it is to hold change B until A is completed. Then:
A potential workaround would be to use the 'Cherry pick' strategy in Gerrit. In this case If A passed, change B would be submitted properly by Gerrit
Note that in both case, if A fails, jobs for B are cancelled and run again so B is retested and merges (eventually).
A problem with cherry-pick is that we review the JJB differences manually. A could potentially have an impact on B so blindly merging B on top of A might have unwanted side effects.
So the process to merge two changes A and B is:
Maybe all the above should be in some FAQ on the wiki ?
I have reopened the task and rephrased it. It is worth documenting somewhere, I am taking suggestion for a text and location of such doc :-}
Also note the cherry-pick strategy causes Gerrit to craft a new patchset on the change which obviously change the commit sha1. That is often unwanted or confusing people, but for integration/config the root cause is the manual checking of JJB diffs when rebasing a change which is a requirement before a +2.
And poked the QA list about it https://lists.wikimedia.org/pipermail/qa/2015-September/002371.html
The summary of the issue is that when two changes got CR+2 only one would merge and the other would be rejected because it is no more fast forward ( T111426#1605970 ).
Via T131008 the repository has been changed to "Rebase if necessary" and "A!!llow content merge". That will allow the second change to be rebased by Gerrit on submit and thus would merge just fine. There should never be a conflict since Zuul already attempt a merge of the second change as if the first had already been merged.
So that is finally fixed properly!!