cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...
Date Mon, 09 Jun 2014 22:46:45 GMT
On Mon, Jun 9, 2014 at 3:14 PM, Rohit Yadav <bhaisaab@apache.org> wrote:
> On Mon, Jun 9, 2014 at 11:32 PM, sebgoa <runseb@gmail.com> wrote:
>
>>
>> On Jun 9, 2014, at 7:13 PM, David Nalley <david@gnsa.us> wrote:
>>
>> > On Mon, Jun 9, 2014 at 11:47 AM, David Nalley <david@gnsa.us> wrote:
>> >> On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang <sheng@yasker.org> wrote:
>> >>> Hi all,
>> >>>
>> >>> Seems it's a good timing to bring back the discussion about the gerrit.
>> >>>
>> >>> We want to do CI, and improve our code quality. One obvious way of
>> doing
>> >>> and reduce the workload of devs is introduce a tool to enforce the
>> process.
>> >>>
>> >>> I've checked out quite a few projects using gerrit, which would force
>> you
>> >>> to ask for review, and validation before the code can be committed to
>> the
>> >>> repo. Looks it's really a easier way for devs according what I've
>> heard.
>> >>>
>> >>> Even our competitor laid out a very detail workflow based on the use
of
>> >>> gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I guess it
>> can
>> >>> make a good reference.
>> >>>
>> >>> Well, gerrit has been brought up a few times before. And now the new
>> >>> process we want to enforce just fits what gerrit(or other automation
>> >>> review/test/commit software) is for.
>> >>>
>> >>> Maybe it's the time for us to review the possibility of using a tool
to
>> >>> enforce our commits and improve our code quality(as well as transfer
>> >>> knowledge) again?
>> >>>
>> >>> --Sheng
>> >>>
>> >>
>> >> ASF Infra has a very dour view on Gerrit. Don't read that as
>> >> impossible; there are many projects at the ASF who are interested in
>> >> Gerrit.
>> >> That said; what about moving to using github pull requests instead of
>> >> RB, and from their, having the jenkins pull request builder
>> >> automatically process every pull request and list information.
>> >>
>> >> Here's an example:
>> >> https://github.com/jclouds/jclouds-labs/pull/61
>> >> You'll see that every time the patch changes, the jenkins plugin
>> >> pulled the patch - ran tests against it and reported back.
>> >>
>> >> That said; it almost seems like we have the cart before the horse; we
>> >> need to finish figuring out the CI Infrastructure first.
>> >>
>> >> --David
>> >
>> > Just as an additional comment.
>> > CF was using gerrit, and apparently dropped it in favor of GH Pull
>> > Requests plus automated testing with Travis-CI.
>> > I know folks like abayer and jfarrell are working on turning on
>> > automated builds via the github pull request plugin for jenkins. Might
>> > be something to consider.
>>
>> fwiw, I have my personal cloudstack fork on github with a simple travisCI
>> setup.
>> So when I make a commit it automatically triggers a build.
>> I was working on running the integration tests on Travis as well but got
>> distracted.
>>
>> If somebody wants to step in:
>>
>> https://github.com/runseb/cloudstack/blob/master/.travis.yml
>
>
> This would be great if we could just use Github (pull requests, releases)
> and hook up Travis-CI. Both are free for opensource projects.
>

To stop us from going down a bad road.
We have to use the ASF repo as the canonical repo. We can use the
github mirrors.

Also - I am not sure if travis-ci would give us free services when the
CI stuff we are talking about needing is well into 6 figures.

--David

Mime
View raw message