On Wed, Dec 9, 2015 at 10:05 AM, Eyal Edri <eedri@redhat.com> wrote:
+1,
this will be the best suggestion.
we can try adding a manual trigger for drafts if needed, still need to check if possible.

e.

On Wed, Dec 9, 2015 at 9:38 AM, Eli Mesika <emesika@redhat.com> wrote:


----- Original Message -----
> From: "Barak Korren" <bkorren@redhat.com>
> To: "Amit Aviram" <aaviram@redhat.com>
> Cc: "infra" <infra@ovirt.org>
> Sent: Tuesday, December 8, 2015 5:16:30 PM
> Subject: Re: Actively triggering of CI jobs
>
> > I was thinking, maybe it would be better if we will explicitly require to
> > run the CI jobs when we push patches.. then only when the developer will
> > need the job's feedback it will be activated. no redundant jobs will run,
> > and we will wait much less for the jobs to finish when we will actually
> > need
> > them.

Why not simply submit your patches as a Draft until the point you want CI to run on them, then you can simply publish them ...
This is the way I am using and it's simple ...

> >
> It seems to me that it will me too easy to forget to run the CI this way.
We barely merge patches that did not pass the CI tests.. only if it fails on general errors that doesn't belong the patch's context. but it is part of the developing process, we can't just forget to using it. that means that it is mandatory to run it at some point if a developer wants his patches to be merged. which means the developer runs it only when it is ready to be merged. (much much less triggered jobs!) 
 
>
> There is another way though - To make the jobs do a lot less work.
> Most anything has to do what what actually happens in CI resides in
> the project`s automation directory now days (see [1]).  If you want to
> make CI smarter so it will not do things it shouldn't be doing, all
> you need to do is customize the automation scripts to be smarter and
> run only the needed tests for the files that were changed by the
> patch.
>
> [1]: http://www.ovirt.org/CI/Build_and_test_standards
>
That's nice, but most of us are not aware of all that..
 
> --
> Barak Korren
> bkorren@redhat.com
> RHEV-CI Team
> _______________________________________________
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra





--
Eyal Edri
Supervisor, RHEV CI
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)

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)
- sometimes I need to label my patches, therefor can't make it a draft

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 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..)