Actively triggering of CI jobs

[Amit Aviram]

On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dcaro at redhat.com> wrote:

> On 12/09 12:00, Amit Aviram wrote:
> > On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren at redhat.com>
> wrote:
> >
> > > >>> > [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...
> >
> >
> > What I'm offering is not letting us a choice, exactly because what you
> are
> > saying regarding the fact that most of the influence of what happens in
> CI
> > is in our hands. otherwise what happens is the current situation where
> > some/most of the developers are not aware of their options, or misses the
> > mails or whatever..
> >
> >
> > > >
> > > > 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)
> > >
> > > Well, 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?
> > >
> >
> > Most of the review process doesn't need the jobs to run. a patch has
> 5-10,
> > and sometimes much more sets until it is being merged- you don't need to
> > run the jobs every single time you are updating your patch..
> >
> >
> > >
> > > >
> > > > 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'.
> >
> >
> > The workflow makes job DISABLING optional.
> > I'm suggesting making job ENABLING optional, with some other flag..
> > As we must run it to merge- it won't be missed, and will be triggered
> only
> > when needed.
>
> That's not true, the workflow make job enabling optional, if you don't set
> it,
> it will not run
>

So I think we should use it :)
Why was it rejected?


> >
> >
> >
> > >
> > > --
> > > Barak Korren
> > > bkorren at redhat.com
> > > RHEV-CI Team
> > >
>
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20151209/1d4b42b3/attachment.html>