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

[Kaleb S. KEITHLEY]

<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