[
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)
_______________________________________________
Infra mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/infra
