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

Luis Pabon lpabon at redhat.com
Mon May 12 20:27:48 UTC 2014


My $0.02, anything that can be done automated, should be done without 
waiting for human intervention.  If we can help parallelize the 
workflow, even better.  The only 'blocker' should be a human review and 
verification.

- Luis

On 05/12/2014 04:04 PM, Anand Avati wrote:
>
>
>
> On Mon, May 12, 2014 at 11:26 AM, Anand Avati <avati at gluster.org 
> <mailto:avati at gluster.org>> wrote:
>
>
>
>
>     On Mon, May 12, 2014 at 11:21 AM, Kaleb S. KEITHLEY
>     <kkeithle at redhat.com <mailto:kkeithle at redhat.com>> wrote:
>
>
>         Then maybe we should run regression tests on check-in. I'm
>         getting tired of queuing up regression tests. (And I know I'm
>         not the only one doing it.)
>
>         Or run them after they pass the smoke test,
>
>         Or....
>
>
>     If we can make regression test trigger automatically, conditional
>     on smoke-test passing, that would be great. Last time I checked I
>     couldn't figure how to (did not look very deep) and left it manual
>     trigger.
>
>
>
> And yeah, the other reason: if a dev pushes a series/set of dependent 
> patches, regression needs to run only on the last one (regression 
> test/voting is cumulative for the set). Running regression on all the 
> individual patches (like a smoke test) would be very wasteful, and 
> tricky to avoid (this was the part which I couldn't solve)
>
> Avati
>
>     Avati
>
>
>
>
>         On 05/12/2014 02:17 PM, Anand Avati wrote:
>
>             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 <mailto:kkeithle at redhat.com>
>             <mailto:kkeithle at redhat.com <mailto: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>
>                     <mailto:ndevos at redhat.com <mailto:ndevos at redhat.com>>
>                     <mailto:ndevos at redhat.com
>             <mailto:ndevos at redhat.com> <mailto: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>
>             <mailto:Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>>
>                     <mailto:Gluster-devel at gluster.
>             <mailto:Gluster-devel at gluster.>__org
>                     <mailto:Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>>>
>
>             http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>             <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>
>
>
>
>                     --
>                     Raghavendra G
>
>
>                     _________________________________________________
>
>                     Gluster-devel mailing list
>             Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>
>             <mailto:Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>>
>             http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>             <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>
>
>                 --
>
>                 Kaleb
>
>                 _________________________________________________
>
>                 Gluster-devel mailing list
>             Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>
>             <mailto:Gluster-devel at gluster.org
>             <mailto:Gluster-devel at gluster.org>>
>             http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
>                
>             <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/c682efb3/attachment-0002.html>


More information about the Gluster-devel mailing list