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

Tue May 13 12:20:11 UTC 2014

May be this will help ?
http://ci.openstack.org/zuul/
http://ci.openstack.org/zuul/reporters.html#gerrit

Openstack uses it. I do know much about Zuul but I guess it's worth looking into.

Regards,
 -Prashanth Pai

----- Original Message -----
From: "Anand Avati" <avati at gluster.org>
To: "Kaleb S. KEITHLEY" <kkeithle at redhat.com>
Cc: gluster-devel at gluster.org
Sent: Monday, May 12, 2014 11:56:30 PM
Subject: Re: [Gluster-devel] Automatically building RPMs upon patch	submission?

On Mon, May 12, 2014 at 11:21 AM, Kaleb S. KEITHLEY < 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. 

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 >> 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 

_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel