| SCM trigger in Hudson with Buckminster? [message #537413] |
Wed, 02 June 2010 07:44  |
Eclipse User |
|
|
|
Hi,
since I use Buckminster inside Hudson to fetch the source code the
possibility is gone to start builds based on changes in the repository (as
Hudson itself does only checkout the releng plugin).
I see two ways of resolving this: either doing only time-based builds or
creating another "dummy job" which does nothing except listening for code
changes and triggering the original job.
Are there any best practices how people are doing this? Looking forward to
your replies.
Regards,
Axel
|
|
|
|
|
| Re: SCM trigger in Hudson with Buckminster? [message #537477 is a reply to message #537433] |
Wed, 02 June 2010 10:47  |
| Eclipse User |
|
|
|
Hi Alex and Johannes,
On 06/02/2010 02:40 PM, Johannes Utzig wrote:
> Hi Alex,
>
> there have been discussions about this before. In theory the Buckminster
> Hudson Plugin could declare itself as an SCM (just like the SVC plugin)
> and delegate the responsibilities for checkout, polling, changelog,
> update,... to Buckminster.
> However, this is currently not implemented in buckminster so I cannot
> provide it in the Hudson Plugin either.
I'm not sure it will be either. Instead, I think we need a more elaborate way to declare repositories and local paths
within them. We should separate the actual repository declaration from the providers that make use of the repository.
With an approach like that it will be much easier to integrate with Hudson and have Hudson be the one that checks out a
whole tree of things that Buckminster then can perform various discovery in to find projects, bind them to the
workspace, share them correctly etc.
Most of these thoughts are captured in the new b3 model and since we plan to make Buckminster one of the first engines
that can run that model, this is also something that we will need to add to Buckminster.
Regards,
Thomas Hallgren
|
|
|
| Re: SCM trigger in Hudson with Buckminster? [message #537492 is a reply to message #537477] |
Wed, 02 June 2010 11:31 |
| Eclipse User |
|
|
|
Hi Thomas,
this sounds very reasonable. If I understood this correctly those changes
would also introduce further advantages: by separating the repository
declarations from the providers one can easier reuse different locations
within this repository. At the moment you have to carry around the
repository (and depending on your protocol even the auth credential
properties) within multiple provider definitions pointing to certain sub
folders (e.g. doc/, examples/, features/, etc.) If a repository would be
defined once and described by a unique id providers could refer to those ids
(maybe even to multiple ones whereby the order defines the weight).
Regards
Axel
Thomas Hallgren wrote:
> Hi Alex and Johannes,
>
> On 06/02/2010 02:40 PM, Johannes Utzig wrote:
>> Hi Alex,
>>
>> there have been discussions about this before. In theory the Buckminster
>> Hudson Plugin could declare itself as an SCM (just like the SVC plugin)
>> and delegate the responsibilities for checkout, polling, changelog,
>> update,... to Buckminster.
>> However, this is currently not implemented in buckminster so I cannot
>> provide it in the Hudson Plugin either.
>
> I'm not sure it will be either. Instead, I think we need a more elaborate
> way to declare repositories and local paths within them. We should
> separate the actual repository declaration from the providers that make
> use of the repository. With an approach like that it will be much easier
> to integrate with Hudson and have Hudson be the one that checks out a
> whole tree of things that Buckminster then can perform various discovery
> in to find projects, bind them to the workspace, share them correctly etc.
>
> Most of these thoughts are captured in the new b3 model and since we plan
> to make Buckminster one of the first engines that can run that model, this
> is also something that we will need to add to Buckminster.
>
> Regards,
> Thomas Hallgren
|
|
|
| Re: SCM trigger in Hudson with Buckminster? [message #537512 is a reply to message #537492] |
Wed, 02 June 2010 13:00 |
| Eclipse User |
|
|
|
On 06/02/2010 05:31 PM, Axel Guckelsberger wrote:
> Hi Thomas,
>
> this sounds very reasonable. If I understood this correctly those changes
> would also introduce further advantages: by separating the repository
> declarations from the providers one can easier reuse different locations
> within this repository. At the moment you have to carry around the
> repository (and depending on your protocol even the auth credential
> properties) within multiple provider definitions pointing to certain sub
> folders (e.g. doc/, examples/, features/, etc.) If a repository would be
> defined once and described by a unique id providers could refer to those ids
> (maybe even to multiple ones whereby the order defines the weight).
>
Exactly.
-thomas
|
|
|
Powered by
FUDForum. Page generated in 0.22055 seconds
Home