Re: Automatically building RPMs upon patch submission?

[Luis Pabon <lpabon@xxxxxxxxxx>]

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@xxxxxxxxxxx> wrote:

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.

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

        <mailto:Gluster-devel@gluster.__org
        <mailto:Gluster-devel@xxxxxxxxxxx>>

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

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

    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