[Gluster-devel] Automatically building RPMs upon patch submission?
Anand Avati
avati at gluster.org
Mon May 12 18:17:51 UTC 2014
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>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>> 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>
>>
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>>
>>
>> --
>> Raghavendra G
>>
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
>>
> --
>
> Kaleb
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140512/9cf13929/attachment-0002.html>
More information about the Gluster-devel
mailing list