[JIRA] (OVIRT-1852) Make change-queue handle continues steaks of failed patches together

[Barak Korren (oVirt JIRA)]

     [ https://ovirt-jira.atlassian.net/browse/OVIRT-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Barak Korren reassigned OVIRT-1852:
-----------------------------------

    Assignee: Barak Korren  (was: infra)

> Make change-queue handle continues steaks of failed patches together
> --------------------------------------------------------------------
>
>                 Key: OVIRT-1852
>                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1852
>             Project: oVirt - virtualization made easy
>          Issue Type: Improvement
>          Components: Change Queue
>            Reporter: Barak Korren
>            Assignee: Barak Korren
>
> Lets assume we have a change queue testing projects 'a' and 'b' where patches had been submitted in the following order (from left to right):
> a1 a2 a3 a4 b1 a5
> Lets further assume that a1 and b2 both introduced regressions to their respective projects, and a5 fixed the regression for project 'a'.
> When running with all changes the CQ test will fail, and it will then run the bisection process testing the following sets of changes (where all tests will fail):
> a1 a2 a3
> a1 <- a1 will be removed from the queue following this
> a2 a3 a4 b1 a5
> a2 a3
> a2 <- a2 will be removed from the queue following this
> a3 a4 b1 a5
> a3 a4
> a3 <- a3 will be removed from the queue following this
> a4 b1 a5
> a4 <- a4 will be removed from the queue following this
> b1 a5
> b1 <- b1 will be removed from the queue following this
> a5 <- This run will finally succeed letting the build of 'a' go the 'tested'.
> As we can see for the case described we will need 14 test runs to clear the queue and find a stable state.
> We can optimize this using the fact that change queue can track individual projects as change streams, and furthermore, the queue knows in every point in time which change streams exhibited failure so far. What we can do is when calculating a bisection, check if the 1st change in the queue belongs to a know failing project, at this point test it individually rather then performing a bisection of the full queue.
> With the starting conditions as described above, the sets of changes being tested would be:
> a1 a2 a3 a4 b1 a5
> a1 a2 a3 <- We are starting a normal bisection here because at this point there is
>                      not yet any knowledge about the failures in 'a'
> a1 <- a1 will be removed and the failure in 'a' will be recorded
> a2 a3 a4 b1 a5 
> a2 <- Now the mechanism described above kicks in and a3 is tested alone
>            and removed
> a3 a4 b1 a5 
> a3 <- Same mechanism now causes a2 to be tested alone
> a4 b1 a5
> a4 <- a4 will be removed from the queue following this 
> b1 a5
> b1 <- b1 will be removed from the queue following this
> a5 <- This run will finally succeed letting the build of 'a' go the 'tested'.
> So a total of 12 test runs - we save 2 test runs,. This can be significant in terms of time saving and more runs an be saved the more failing patches we have.



--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100076)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20180118/42831135/attachment.html>