Actively triggering of CI jobs

[Barak Korren]

>>> > [1]: http://www.ovirt.org/CI/Build_and_test_standards
>>> >
>
> That's nice, but most of us are not aware of all that..
>

Well, we can do a better job advocating that, I try to mention this
almost in any infra/devel thread where 'CI' is mentioned.
I'm open to suggestions about how to make developers more aware of the
fact that the ultimate power to determine what happens in CI had
mostly been placed in their hands...

>
> From what I'm seeing, most of the developers here don't make their patches
> drafts.. moreover,
> - personally I didn't even know that it will not trigger jobs if it is a
> draft. (and I'm not the only one)

We, now you know... Adding 'devel' with hope more devs will read this.

> - sometimes I need to label my patches, therefor can't make it a draft
>
By 'label' you mean set topic?
Not sure those are mutually exclusive, 'git review' options seem to
indicate they are not. I will look deeper into that.

> nowadays we are waiting for the jobs too much to finish. and the reality is
> that too much jobs shouldn't run at all- despite all of the nice things you
> guys show here..

I which cases besides the patch not being "ready" (=draft...)  should
jobs not run?

>
> I still think that it will be a better solution to force the developer to
> activate the tests manually (by adding a flag when pushing or even doing it
> with the jenkins client..)
>
We tried to add the 'workflow' flag for that at some point (It is used
by most infra projects), but it was not accepted with any enthusiasm
by the devs, you can search back the discussion on 'devel'.


-- 
Barak Korren
bkorren at redhat.com
RHEV-CI Team