[Gluster-devel] Automatically building RPMs upon patch submission?

[Raghavendra G]

+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> 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
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140512/8ef47575/attachment-0002.html>