[Gluster-devel] Automatically building RPMs upon patch submission?
Anand Avati
avati at gluster.org
Mon May 12 18:26:30 UTC 2014
On Mon, May 12, 2014 at 11:21 AM, Kaleb S. KEITHLEY <kkeithle at redhat.com>wrote:
>
> Then maybe we should run regression tests on check-in. I'm getting tired
> of queuing up regression tests. (And I know I'm not the only one doing it.)
>
> Or run them after they pass the smoke test,
>
> Or....
If we can make regression test trigger automatically, conditional on
smoke-test passing, that would be great. Last time I checked I couldn't
figure how to (did not look very deep) and left it manual trigger.
Avati
>
>
> On 05/12/2014 02:17 PM, Anand Avati wrote:
>
>> It is much better to code review after regression tests pass (premise
>> being human eye time is more precious than build server run time)
>>
>>
>> On Mon, May 12, 2014 at 10:53 AM, Kaleb S. KEITHLEY <kkeithle at redhat.com
>> <mailto:kkeithle at redhat.com>> wrote:
>>
>> <top-post>
>> How about also an auto run of regression at +1 or +2 code review?
>> </top-post>
>>
>>
>> On 05/12/2014 01:49 PM, Raghavendra G wrote:
>>
>> +1 to create RPMs when there is atleast a +1 on code review.
>>
>>
>> On Mon, May 5, 2014 at 8:06 PM, Niels de Vos <ndevos at redhat.com
>> <mailto:ndevos at redhat.com>
>> <mailto:ndevos at redhat.com <mailto:ndevos at redhat.com>>> wrote:
>>
>> On Mon, May 05, 2014 at 07:13:14PM +0530, Lalatendu Mohanty
>> wrote:
>> > On 05/02/2014 04:07 PM, Niels de Vos wrote:
>> > >Hi all,
>> > >
>> > >at the moment we have some duplicate RPM-building tests
>> running:
>> > >
>> > >1. upon patch submission, next to smoke (compile+posix)
>> tests
>> > >2. rpm.t in the regression tests framework
>> > >
>> > >Both have their own advantages, and both cover a little
>> different
>> > >use-case.
>> > >
>> > >Notes and observations for 1:
>> > >
>> > > The advantage of (1) is that the built rpm-packages
>> are made
>> available
>> > > for downloading, and users can test the change easier.
>> > >
>> > > It is unclear to me how often this is used, many
>> patches need
>> several
>> > > revisions before they get accepted, each new
>> revision gets new
>> > > packages build (takes time for each patch
>> submission). I do
>> not know
>> > > how long these packages are kept, or when they are
>> deleted.
>> > >
>> > > Building is done for EPEL-6 and Fedora (exact
>> version unclear
>> to me).
>> > >
>> > >
>> > >Notes and observations for 2:
>> > >
>> > > Building is only done when there are changes related
>> to the
>> packaging.
>> > > When there are only changes in source code or
>> documentation,
>> there is
>> > > no need to try and build the rpms (saves ca. 5
>> minutes).
>> > >
>> > > The packages are build for EPEL-5 and EPEL-6 only.
>> The resulting
>> > > packages are deleted automatically and can not be
>> downloaded.
>> > >
>> > > When writing rpm.t, we decided that building for
>> Fedora was a
>> little
>> > > dangerous, there are the occasional incompatible
>> changes
>> introduced.
>> > > We also don't want to bother every developer too
>> much with the
>> > > packaging.
>> > >
>> > >
>> > >Suggestion for improving the current duplicate package
>> building:
>> > >
>> > > Building packages takes a lot of resources. It does
>> not seem
>> efficient
>> > > to me to build packages for two EPEL-6 and Fedora
>> for each patch
>> > > submission. This takes additional time for a check
>> (smoke.sh)
>> that is
>> > > tried to keep quick. I also doubt that many of the
>> generated
>> packages
>> > > are actually used by anyone. Most developers
>> (hopefully) test
>> their
>> > > changes before submitting the patch(es) to Gerrit.
>> > >
>> > > There is a definite need to verify that the
>> packaging still
>> works, it
>> > > helps to catch packaging errors as early as
>> possible. Testing
>> each
>> > > patch submission might be overkill. Creating
>> packages as part
>> of the
>> > > regression tests (and make them available) might be
>> too late,
>> > > regression testing tends to take quite long.
>> > >
>> > > From my understanding, the only users that are
>> interested in
>> these
>> > > very early packages, are the QA folks. We definitely
>> want
>> them to test
>> > > whatever the developers change, so we should
>> accommodate them
>> as much
>> > > as possible.
>> > >
>> > > After some discussion, Pranith tossed the idea about
>> building
>> packages
>> > > when at lease some review of the change has been
>> done. I
>> think this is
>> > > a great idea! So, I'd like to propose building
>> packages when
>> at least
>> > > one +1 has been given on a change. Alternatively, it
>> should be
>> > > possible for the QA people to submit a Jenkins job
>> that
>> builds the
>> > > packages earlier already. This can then replace both
>> current
>> building
>> > > jobs.
>> > >
>> > >
>> > >Ideas and further discussions are very much welcome,
>> thanks,
>> > >Niels
>> > >
>> > >Related: http://review.gluster.org/7610
>> >
>> > I am not sure if we have a Jenkins job to create RPM for a
>> > particular change-id. if not, we should have one. Should
>> we also
>> > plan for "deb" (Debian packages) too? As we have quite
>> a few users
>> > using Debian/Ubuntu distribution.
>>
>> Yes, .deb would be a next step, probably followed by NetBSD
>> and OSX.
>>
>> Any objections if the current devrpms jobs (upon patch
>> submission) will
>> be removed, and inserted at a +1 Code-Review or +1
>> Verified? Any
>> volunteers that know Jenkins and its Gerrit integration
>> well enough to
>> make this happen?
>>
>> I have no idea how to create Jenkins jobs that can create
>> RPMs, probably
>> Luis can help with that.
>>
>> Thanks,
>> Niels
>> _________________________________________________
>>
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>> <mailto:Gluster-devel at gluster.__org
>> <mailto:Gluster-devel at gluster.org>>
>>
>> http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>> <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>>
>>
>>
>>
>> --
>> Raghavendra G
>>
>>
>> _________________________________________________
>>
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>> http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>> <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>>
>>
>> --
>>
>> Kaleb
>>
>> _________________________________________________
>>
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org <mailto:Gluster-devel at gluster.org>
>> http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>> <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>>
>>
>>
> --
>
> Kaleb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140512/604035f5/attachment-0002.html>
More information about the Gluster-devel
mailing list