[Gluster-devel] Automatically building RPMs upon patch submission?
Anand Avati
avati at gluster.org
Mon May 12 20:04:45 UTC 2014
On Mon, May 12, 2014 at 11:26 AM, Anand Avati <avati at gluster.org> wrote:
>
>
>
> 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.
>
>
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>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140512/d39e2497/attachment-0002.html>
More information about the Gluster-devel
mailing list