[JIRA] (OVIRT-1918) Single project tests in change-queue-tester

[Barak Korren (oVirt JIRA)]

    [ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35974#comment-35974 ] 

Barak Korren commented on OVIRT-1918:
-------------------------------------

{quote}
I'm not sure that the bisection really works then, since we have still packages released 2 months ago not yet landing on tested. I don't recall to have seen any job triggered automatically after a change-queue-tester failure doing bisection tests.
{quote}

It works. 'change-queue-tester' itself gets re-triggered by 'change-queue' with a different set of patches after failure. Only failures that were narrowed down to a single patch are reported to infra-list.

You can see the state of the queue an the bisection status in a graphical display on the status page of the  'change-queue' job.

If you see something that wasn't moved to tested it can be because:
# the HEAD itself that was tested is really broken
# some build job failed because of an infra issue (e.g s390x/fcraw issue)
# OST itself was broken at the time of the test

"ci re-merge please" is for handling the last 2 reasons, essentially [~dron] or the infra owner is supposed to be monitoring the CQ reports, detecting theses cases and issuing "ci re-merge please"  as needed.

> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20180306/aed33c4e/attachment.html>