On 12/09 12:00, Amit Aviram wrote:
> On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren@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

>
>
>
> >
> > --
> > Barak Korren
> > bkorren@redhat.com
> > RHEV-CI Team
> >

> _______________________________________________
> Infra mailing list
> Infra@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@redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605