4: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--