<html><body>
<pre>[ https://ovirt-jira.atlassian.net/browse/OVIRT-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35974#comment-35974 ]</pre>
<h3>Barak Korren commented on OVIRT-1918:</h3>
<p>{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}</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<p>“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.</p>
<blockquote><h3>Single project tests in change-queue-tester</h3>
<pre> 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</pre>
<p>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 <<a href="https://www.redhat.com/">https://www.redhat.com/</a>> <<a href="https://red.ht/sig">https://red.ht/sig</a>> TRIED. TESTED. TRUSTED. <<a href="https://redhat.com/trusted">https://redhat.com/trusted</a>></p></blockquote>
<p>— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100081)</p>
<img src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpSp2-2BJ33BSM3tuiUfRTk64K-2BOjGpF-2BuMzoJRRB1ifzZIErtIxTccLy521zz7OxZViB5mnpbbwYJFz6flgevXOzUJVH-2FqBqvcqqqKIp3p4OcyDFOsRwvaLk1r7X8JpLEbbYtQ-2F8se-2FAoG3NqMy6MEF960fM4WCfArIPipDAxV3I9QtDxwIZkeNWD9yApPsdJra3V4NT7hIOoTif46hN9A2Na-2BIseHngSSOzrSPo87Xs5dlTOp9S0KFEUcZIQ-2FQzJc-2BEixANiBJJULW94Lp5YjSZa9DUysHty07Pkeg7VLLHrFJHqYEdqI5ZP1eTvSv-2FRXaPWvvOl8WI1KwXfFiuIYizf8N29xiU0fWmbPgDwMn2qu89gGi31zY-2F7QSN3HeAns9pBR3C57zkyHh5U6cCTMfpM-2FFb-2BPxlpBY84L236o63OfX46M" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>