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@xxxxxxxxxxx> To: "Kaleb S. KEITHLEY" <kkeithle@xxxxxxxxxx> Cc: gluster-devel@xxxxxxxxxxx Sent: Monday, May 12, 2014 11:56:30 PM Subject: Re: Automatically building RPMs upon patch submission? On Mon, May 12, 2014 at 11:21 AM, Kaleb S. KEITHLEY < kkeithle@xxxxxxxxxx > 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@xxxxxxxxxx <mailto: kkeithle@xxxxxxxxxx >> 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@xxxxxxxxxx <mailto: ndevos@xxxxxxxxxx > <mailto: ndevos@xxxxxxxxxx <mailto: ndevos@xxxxxxxxxx >>> 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@xxxxxxxxxxx <mailto: Gluster-devel@gluster. org > <mailto: Gluster-devel@gluster. __org <mailto: Gluster-devel@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@xxxxxxxxxxx <mailto: Gluster-devel@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@xxxxxxxxxxx <mailto: Gluster-devel@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@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
