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

[sbonazzo (oVirt JIRA)]

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

sbonazzo commented on OVIRT-1918:
---------------------------------

bq. Maybe we need to use always the official release repo as fallback to tested?

I don't think so. Tested repo should not require official release repo.
Official release should be eventually generated from tested repo, not the other way around.

bq. In case a specific PKG failed to build and it's maintainer didn't make sure
bq. to fix it and redeploy, it makes sense to get missing pkgs from latest
bq. official release, as we do in OST.

How a pacakge maintainer will know that a package didn't land in tested?
It tooks me 2 months to discover we have packages not getting in tested and I noticed just by mistake.
And I'm one of those maintainers that cares a lot about packages being published.

bq. Once the maintainer of the project will build a new image and it passes, it
bq. will be in tested.

That's not always true. I had several packages that required me to issue "ci re-merge please" multiple times before getting to tested repo without any code change on the project itself.


> 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/3af5390c/attachment.html>