Run OST flow as a merge gate (Patch gating)
Description
blocks
Activity

Barak Korren December 1, 2016 at 10:56 AMEdited
Changed subject to perhaps make it clearer

Barak Korren December 1, 2016 at 10:55 AM
talks about using Zuul for gating (It mentions check_merged but I'm guessing this is just part of the gating process).
But maybe we should have separate tickets because we will probably implement this in phases:
Setup Zuul
Make Zull manage check_patch
Make Zuul run check_merged as a gate
Add experimental flow to the gate
So I'm guessing this ticket is the 4th part...

Eyal Edri December 1, 2016 at 10:49 AM
Might be, if 734 also talks about creating a new flow to mimik/replease the existing 'deploy to experimental' + 'test experimental' then yes, its a duplicate.
If it just includes the framework work needed to connect Zuul to Gerrit, then no.

Barak Korren December 1, 2016 at 10:10 AM
Isn't this a duplicate of ?

Eyal Edri December 1, 2016 at 8:50 AM
I guess this is the second step after we see Zuul integration works.
I think the 1st thing we should do is create some sort of design diagram of how we want the flow to work and what input/output/triggers it should have.

Eyal Edri September 18, 2016 at 2:43 PM
Actually replacing the existing flows which run post merge, we need to check if its possible to run pre-merge with Zuul the entire flow and reject patches if it fails.

Eyal Edri August 28, 2016 at 11:35 AM
this might be relevant for your task on moving ovirt-engine to lago.

Eyal Edri August 3, 2016 at 10:18 AM
Instead of adding a manual job, we just need to clone the current build-artifacts flow with the deploy script and experimental test job.
the build artifacts can be lighter and not include all permutations.
Details
Assignee
UnassignedUnassignedReporter
Eyal EdriEyal EdriComponents
Priority
Medium
Details
Details
Assignee
Reporter

Our oVirt change queue today check patches after they have been merged to the relevant projects.
When working post-merge, the change queue currently allows to separate between patches to different projects, but if a broken patch is merged into a project, the relevant branch in that project remains broken until a fix patch is merged.
This is an issue for big project like '
ovirt-engine
' where there may be multiple unrelated changes that end up blocking each other.This is also needed if we decide we want to provide system tests results to developers before things get merged.