brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: Jenkins set up for new-repo Brooklyn builds
Date Tue, 02 Feb 2016 16:01:02 GMT

Yavor thanks!

I'm happy with OPT 2.

The Apache server has the Multiple SCM plugin installed.

Do you think rather than go through the steps again we could install a 
tarball of the on-box configuration?  ISTR jenkins allows that.  Failing 
that some other type of import/export maybe?  Especially given it's now 
15 jobs and we aren't counting running doc tests or live tests!

Best
Alex


On 02/02/2016 15:57, Yavor Yanchev wrote:
> Hi Alex,
>
> I can setup it. Starting from the internal server than documenting the 
> steps so they can be applied for the Apache instance by a commiter.
>
> I've tested the option 1) on a test box. It works as expected, but 
> requires an external plugin. Not sure, if it is already available on 
> the Apache's instance or
> to be requested for installation by the Infra team.
> Multiple SCM plugin is just a wrapper with some advanced features such 
> as module support which fits in our use case.
>
> IMHO, we should take the second option. It will require some extra 
> manual work, but at the end it will look more accurate and descriptive.
>
> Regards,
> Yavor
>
> On 02/02/2016 11:00 AM, Alex Heneveld wrote:
>> Hi All-
>>
>> So far so good with the new repos...
>>
>> We now need to get Jenkins set up.  There are a couple options now, 
>> due to the submodules, especially when it comes to pull requests.
>>
>> We could keep the same pattern as we currently have -- 1 below -- 
>> although I'm not sure whether multi-project / sub-modules
>> is going to play nicely.  (There is a "Multiple SCM" option in 
>> jenkins.)  Option 2 has many more jobs though that would mean faster
>> response on builds.
>>
>> WDYT?  Anyone love Jenkins and want to configure this?  (I've taken a 
>> stab at a brooklyn-master-build.)
>>
>>
>> OPTION 1 -- multiple scm
>> * brooklyn-pull-requests monitors all 6 repos, will the pull request 
>> trigger enabled
>> * brooklyn-master monitors all 6 repos, will commit trigger and a 
>> daily trigger
>>     (the above both don't checking out the submodules, but instead 
>> follow the "avoiding submodules" trick described)
>> * brooklyn-master-windows and brooklyn-master-integration triggered 
>> on brooklyn-master-build success, checkout out sub-modules
>>
>> OPTION 2 -- job per scm
>> * brooklyn-server-pull-requests builds when brooklyn-server has PR
>> * brooklyn-server-master builds when brooklyn-server has commits
>> * 10 others -- 
>> brooklyn-{dist,docs,library,client,ui}-{master,pull-requests} as above
>> * brooklyn-master-build is built on any brooklyn-*-master success and 
>> a daily trigger, checkout out sub-modules
>> * brooklyn-master-windows and brooklyn-master-integration triggered 
>> on brooklyn-master-build success, checkout out sub-modules
>>
>> OPTION 3 -- hybrid
>> * brooklyn-*-pull-requests as per (2)
>> * brooklyn-master-build as per (1)
>>
>> Best
>> Alex
>>
>
>


Mime
View raw message