Is seems that despite the fact that all the jobs involved were designed to preserve proper patch ordering, there can be cases where patches trigger Jenkins jobs in the wrong order, which in turn end up putting the patches in the wrong order into the CQ. This in turn, causes the CQ to fail accurately detecting the patches that cause issues.
Here is en example of such an occurance. The following patches were merged in the order specified below:
The standard-enqueue runs putting them in the CQ however, seem to have run in a different order:
This resulted in CQ 'add' command running in the wrong order:
We need to come up with a way to make the system properly preserver order.
since this issue only happened with vdsm-jsonrpc-java AFAIK, due to its tight integration with engine, How often would you say such issue happens? can we allow for a delay between version bumps patches of the project to try and avoid it until we implement a permenant solution?
email@example.com I do not think it is related only to vdsm-jsonrpc-java and it my opinion it can happen for anyone. In general I give couple of hrs between merging jsonrpc version update patch and the engine patch. Do you have any specific time in your mind for how long should I wait?
I think we've seen it so far only on vdsm-jsonrpc-java, but maybe I'm not aware of all the incidents.
Also, differ between the old way we published in 4.1 ( copy from job ) and the new flow in 4.2 with CQ, which is a different issue than before.
I think 1 hour should suffice, but it depends on how loaded the CQ is, any thoughts?
I think 1 hour should suffice, but it depends on how loaded the CQ is, Barak Korren any thoughts?
There is no need to wait one hour and this has nothing to do with the delay between merging 'vdsm-jsonrpc-java' and 'ovirt-engine'. The issue discussed in this ticket is triggered when reviewing a series of patches and merging all of then together by clicking the "submit with parents" button on a child patch in Gerrit. As long as patches are merged individually by clicking on the "merge" button for each one the issue shouldn't arise.
This issue should not be confused with the need to do dependency handling so that equivalent versions of engine and 'vdsm-jsonrpc-java' are tested together. That is tracked in OVIRT-1662.
Yes, I am guilty of this one. I often do that and as far as I know other people are doing it. If that is the issue I can trigger merges one by one but we would have usablility issue :|.