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

[Lalatendu Mohanty]

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.

-Lala