9:05 a.m.
Hi all.
I wanted to bring up something that might make our work with CI a bit more
efficient.
As developers, we obviously use Jenkins in every step we are taking in the
developing process. Each patch that is pushed- or at least a big amount of
our patches- triggers Jenkins jobs automatically.
I can say that for myself, most of my push actions do not require any CI
jobs to run. Thus reviewing and updating patches include work that triggers
tons of redundant jobs that make the system slow for the jobs that are
actually needed..
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.
Is that possible for implementation?
Thanks, Amit.
9:16 a.m.
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.
It seems to me that it will me too easy to forget to run the CI this way.
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
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
1:38 a.m.
----- Original Message -----
From: "Barak Korren" <bkorren(a)redhat.com>
To: "Amit Aviram" <aaviram(a)redhat.com>
Cc: "infra" <infra(a)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.
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
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
2:05 a.m.
+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(a)redhat.com> wrote:
----- Original Message -----
> From: "Barak Korren" <bkorren(a)redhat.com>
> To: "Amit Aviram" <aaviram(a)redhat.com>
> Cc: "infra" <infra(a)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.
>
> 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
>
> --
> Barak Korren
> bkorren(a)redhat.com
> RHEV-CI Team
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
_______________________________________________
Infra mailing list
Infra(a)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)
3:10 a.m.
On Wed, Dec 9, 2015 at 10:05 AM, Eyal Edri <eedri(a)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(a)redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Barak Korren" <bkorren(a)redhat.com>
> > To: "Amit Aviram" <aaviram(a)redhat.com>
> > Cc: "infra" <infra(a)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(a)redhat.com
> > RHEV-CI Team
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> _______________________________________________
> Infra mailing list
> Infra(a)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..)
3:35 a.m.
--yhze8HlyfmXt1APY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 12/09 11:10, Amit Aviram wrote:
On Wed, Dec 9, 2015 at 10:05 AM, Eyal Edri <eedri(a)redhat.com>
wrote:
=20
> +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(a)redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Barak Korren" <bkorren(a)redhat.com>
>> > To: "Amit Aviram" <aaviram(a)redhat.com>
>> > Cc: "infra" <infra(a)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
wi=
ll
>> 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 fai=
ls
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!)
=20
=20
> >
>> > 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..
=20
=20
> > --
>> > Barak Korren
>> > bkorren(a)redhat.com
>> > RHEV-CI Team
>> > _______________________________________________
>> > Infra mailing list
>> > Infra(a)ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/infra
>> >
>> _______________________________________________
>> Infra mailing list
>> Infra(a)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)
>
=20
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
=20
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 y=
ou
guys show here..
=20
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..)
That effort was called the Worflow flag, but was discarded as most of the
developers (and managers) did not like it.
It's a new flag (as CI or Verified) that you set whenever you want it to mo=
ve
to the next step of the workflow, in this case, run the ci tests. Some proj=
ects
use it for requesting code reviews (most of infra projects have it), but ca=
n be
easily adapted to have as many values as needed (+1 if it needs review, +2 =
to
run CI jobs for example).
Another thing that would help there, is using personal/feature branches, so=
you
develop your patches on you branch (that does not run any CI) and at any po=
int
you send a merge commit to the destination branch that will run the tests.
This allows:
* Not running any ci on non-finished patches
* For each set of related patches, only one is sent to the destination
branch, that runs only one job (if you send all the patches, it runs f=
or
each)
* You can still see the per-patch history, as the merge commit includes =
that
info (as opposed to squashing it)
Those two options do not conflict either, but both of them require from the
devels to adapt their way of working.
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
--yhze8HlyfmXt1APY
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWZ/XSAAoJEEBxx+HSYmnDY1cH/A2JQcQuidNP19HD9h5Z0l97
LdM2l+SXmRaEWh5zuj3bXJD3j9zVRTQdm0cph3xhNAD3C6WS+xy7203abylJvvIH
/IB8VJPIlcZVLI1gVBcJICGdnNusGeiqh91wnsoO9ei+6KhD/rlPco28ssc2utuY
ICVrrPDSUAP2GNmxcJ0zaT0oK195RZJqzhBma0uJjyxnpvTB+o1dXhOnKDIIHZ+z
eBneU3tgvXo5ZzaZW0bZ8O/PB+wxt3YCl5FfcnCUvOTDII70MOs2hRJ+3fgdXa6a
ULFPHuXE10+oZxUyjA1C6WB2JZPItZ85lXjDEbbzk/Pih8YkNo6vZEywixIU7FY=
=1j1D
-----END PGP SIGNATURE-----
--yhze8HlyfmXt1APY--
3:37 a.m.
>> > [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(a)redhat.com
RHEV-CI Team
4 a.m.
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren(a)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.
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
4:15 a.m.
--VnOTrGv5LmZxna7m
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 12/09 12:00, Amit Aviram wrote:
On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren
<bkorren(a)redhat.com> wrote:
=20
> >>> > [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...
=20
=20
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..
=20
=20
> >
> > 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 i=
s 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 real=
ity
> is
> > that too much jobs shouldn't run at all- despite all of the nice thin=
gs
> you
> > guys show here..
>
> I which cases besides the patch not being "ready" (=3Ddraft...) should
> jobs not run?
>
=20
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..
=20
=20
>
> >
> > I still think that it will be a better solution to force the develope=
r
to
> > activate the tests manually (by adding a flag when pushing
or even do=
ing
> 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'.
=20
=20
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
=20
=20
=20
>
> --
> Barak Korren
> bkorren(a)redhat.com
> RHEV-CI Team
>
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
--VnOTrGv5LmZxna7m
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWZ/9CAAoJEEBxx+HSYmnDB1wIAJ4Zlhlw8xF4sDnmcG8Asilx
GgK6KTbiwr12jVMwuy+F7XF+CdoazchbQhl7tglabsgK8sbhKe7gnnBvSsswvxc7
rszIA351Bx4yNrVeRJVaNR7r+22NK9t6hO57mQENtOddNx2NFDYASzbZKRIiNkns
XxtjmHqQX7eAWYaOo55zpZ3TxLVBPB1vFPXQEvEXVysOJOzFas2naXfvM8Yoib94
GA1uSITMBsMFQWjR0iYtfcH+B5SrUmOh92DcyKhsJa3QM+mQKOc/tzwmMeOxyUbS
ytTWZzcyNmqd/3q3qASZUSVqhTRlmo4QZBfcB0IMLF9f/N1QmIH8ECflMs1TN0c=
=Qy57
-----END PGP SIGNATURE-----
--VnOTrGv5LmZxna7m--
6:09 a.m.
On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dcaro(a)redhat.com> wrote:
On 12/09 12:00, Amit Aviram wrote:
> On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren(a)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(a)redhat.com
> > RHEV-CI Team
> >
> _______________________________________________
> Infra mailing list
> Infra(a)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(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
11:32 a.m.
--PxDrs/Fpf4pPiewX
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 12/09 14:09, Amit Aviram wrote:
On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dcaro(a)redhat.com>
wrote:
=20
> On 12/09 12:00, Amit Aviram wrote:
> > On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkorren(a)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" (=3Ddraft...)
sh=
ould
> > > 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
u=
sed
> > > 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
>
=20
So I think we should use it :)
Why was it rejected?
=20
Most people that answered just did not like the idea, they though
that it was too much extra process for the developer, and that they
had enough with the drafts for now.
=20
> >
> >
> >
> > >
> > > --
> > > Barak Korren
> > > bkorren(a)redhat.com
> > > RHEV-CI Team
> > >
>
> > _______________________________________________
> > Infra mailing list
> > Infra(a)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(a)redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
--PxDrs/Fpf4pPiewX
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJWmS1BAAoJEEBxx+HSYmnDN+AH/0fCGyEhilR+r6RZihUuohyG
5u8uLjWrRm+lYiKouiSlI8iGQ8baFhPAdTlOSGZ09Gsu3yq+Ai1mppQYkPQojRnJ
eMdtSkVvjnVJVxGBxqV405fwuDT2LR0xspRsFVkoi0O7knXWo/N6CkwYKOlA3Kz5
2zO0RtFeLq2YJhAb9M/UrzBIPgLSeTSE4nzpnuF++qfXs/gTdDbrpx5S7yiOgvYQ
3rHiAcL/qQvUfb4Ghah+U01xaAxCZTsbY8rWveuKvOTO6deVLub7zgvcPL8kzZJv
7ehfW97UbnWmCRrooc5ctG/phZAErBztePVs3mWRs57lunR4zRXLdI1trq0vA/U=
=JmCf
-----END PGP SIGNATURE-----
--PxDrs/Fpf4pPiewX--
3018
days inactive
3056
days old
10 comments
5 participants
participants (5)
-
Amit Aviram -
Barak Korren -
David Caro -
Eli Mesika -
Eyal Edri