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

[Niels de Vos]

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