[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