What we have as verify jobs corresponds to what openstack calls check and these 
are not enough to gate commits as you experienced.

If we had zuul, we could have gate jobs using dependent pipeline. [1] Until we 
get zuul, my suggestion to you is to rebase changes before submitting them to 
ensure you rerun verify jobs for the pending change against the latest master. 
But you might find yourself in same situation over and over again if heavy 
development is going on within the project and master is in constant move.

Finding problematic commits is manual work if they slip through. You need to 
check the delta between the latest successful run and failed one.

I'm aware that this is probably not the answer you're looking for but this is 
what we have with the current tooling. I hope openstack releases stable zuul v3 
soon so we try it out.

[1] http://docs.openstack.org/infra/zuul/gating.html#dependent-pipeline


On 30 Nov 2016, at 08:41, Yujun Zhang 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> wrote:

My previous reply is a bit deviated from original question.

The problem was when a bunch of patchsets get merged in a day and then we find 
the daily integration job fails on the next day.

Is there a way to find out quickly which commit breaks the build?

On Wed, Nov 30, 2016 at 3:28 PM Yujun Zhang 
<zhangyujun+...@gmail.com<mailto:zhangyujun%2b...@gmail.com>> wrote:
Hi, Fatih

The verify job works well for each commit.

But when there are several commits in parallel, the one get verified seems not 
identical to the one after merge. For example,

 |   |
 B   C
 +   +
 |   |

1. Both patch B and patch C are submit for review and passed verification job.
2. Patch B is merged, everything is fine.
3. When merging patch C, a merge commit D will be created by CI. Will it get 

On Wed, Nov 30, 2016 at 3:15 PM Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>> wrote:

The purpose of verify jobs is this. Qtip has it so you need to decide what 
other checks you want to have and adjust the job accordingly.



On 30 Nov 2016, at 04:36, Yujun Zhang 
<zhangyujun+...@gmail.com<mailto:zhangyujun+...@gmail.com>> wrote:

During the code refactoring in QTIP project, I found it easily to get things 
broken[1]. And it can only be detected during the daily integration AFTER merge.

Is it possible that we have a gate job to detect such failure before a patchset 
get merged?

I remember it may have been discussed before. Could anybody remind me of the 

opnfv-tech-discuss mailing list
opnfv-tech-discuss mailing list

Reply via email to