Barak Korren commented on OVIRT-1918:

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 

[~dron]/infra-owner is supposed to tell you. This reporting is not fully 
automated yet because of false positives. Specifically WRT build failures you 
already get a comment in Gerrit.

> 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.
> -- 
> 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
Infra mailing list

Reply via email to