Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Buckminster » SCM trigger in Hudson with Buckminster?
SCM trigger in Hudson with Buckminster? [message #537413] Wed, 02 June 2010 11:44 Go to next message
Axel Guckelsberger is currently offline Axel GuckelsbergerFriend
Messages: 354
Registered: July 2009
Senior Member
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 #537433 is a reply to message #537413] Wed, 02 June 2010 12:40 Go to previous messageGo to next message
Johannes Utzig is currently offline Johannes UtzigFriend
Messages: 329
Registered: July 2009
Senior Member
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.
For additional infos please see here
http://issues.hudson-ci.org/browse/HUDSON-6154
and here:
http://www.eclipse.org/forums/index.php?t=msg&th=148810& amp;start=0&

Unless you would be willing to write a patch for Buckminster I can only
suggest to use the approach mentioned in HUDSON-6154
Let Hudson do the checkout and perform a local resolution with
buckminster on the stuff that got checked out by Hudson.

Hope that helps somewhat.

Best regards,
Johannes
Re: SCM trigger in Hudson with Buckminster? [message #537458 is a reply to message #537433] Wed, 02 June 2010 14:05 Go to previous messageGo to next message
Axel Guckelsberger is currently offline Axel GuckelsbergerFriend
Messages: 354
Registered: July 2009
Senior Member
Thanks Johannes.
Re: SCM trigger in Hudson with Buckminster? [message #537477 is a reply to message #537433] Wed, 02 June 2010 14:47 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
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 15:31 Go to previous messageGo to next message
Axel Guckelsberger is currently offline Axel GuckelsbergerFriend
Messages: 354
Registered: July 2009
Senior Member
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 17:00 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
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
Previous Topic:No reader type with id cvs has been registered
Next Topic:"Resource is out of sync with the file system" on Target Definition
Goto Forum:
  


Current Time: Tue Apr 23 16:34:54 GMT 2024

Powered by FUDForum. Page generated in 0.03070 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top