[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35969#comment-35969 ]
Barak Korren edited comment on OVIRT-1918 at 3/6/18 10:55 AM: -------------------------------------------------------------- {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbona...@redhat.com] Unless you need further clarification, I will close this ticket as WONTFIX. was (Author: bkor...@redhat.com): {quote} So, supposing project A and B are completely fine, a failure in project C can still prevent changes in A and B to go ahead through the pipeline and get released. {quote} This statement is false - what will happen in this case is that a bisection search will run and isulate the change to project C, while allowing the changes for A and B to pass. This si the whole point of CQ and the difference between it and the 'experimental' system it replaced. [~sbona...@redhat.com] Un;ess you need further clarification, I will close this ticket as WONTFIX. > Single project tests in change-queue-tester > ------------------------------------------- > > Key: OVIRT-1918 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1918 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: infra > > Please change change-queue-tester jobs for testing a single project at a > time (ok for multiple patches at once, but from the same project). > Right now if multiple patches are merged between a change-queue-tester > execution and the next one are done, all of them will be tested in the next > run, even if the changes are in different projects. > So, supposing project A and B are completely fine, a failure in project C > can still prevent changes in A and B to go ahead through the pipeline and > get released. > This cause major headaches at least to me, requiring me to go again over > all the HEAD of the projects not being published and run yet again "ci > re-merge please" again and again and again until I'm lucky enough to have > nobody else merging patches or having all the ttested patches pass at once. > I understand the need to reduce the amount of executions of the job since > it takes an hour to execute but right now it's stealing days of execution > for getting a patch landing on tested repo. > -- > SANDRO BONAZZOLA > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> -- This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra