brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Jenkins set up for new-repo Brooklyn builds
Date Wed, 03 Feb 2016 05:04:02 GMT
I also added the pull-requests build jobs for server and library. The 
former has 3 PRs in the queue, the latter has none. Looks like they're 
waiting for a bit in the queue. Will check on their results tomorrow.

Cheers,
Hadrian

On 02/02/2016 11:01 AM, Alex Heneveld wrote:
>
> 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