[Gluster-devel] Automatically building RPMs upon patch submission?
Kaleb S. KEITHLEY
kkeithle at redhat.com
Mon May 12 18:21:25 UTC 2014
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....
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>> 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>>> 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>>
>
> 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>
> 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>
> http://supercolony.gluster.__org/mailman/listinfo/gluster-__devel
> <http://supercolony.gluster.org/mailman/listinfo/gluster-devel>
>
>
--
Kaleb
More information about the Gluster-devel
mailing list