[buckminster-dev] Re: Tutorial for building an RCP from hudson

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Thomas,

I was reading some more and here is what I found out so far:

> OK, let's try and resolve this. My knowledge of Hudson is very limited 
> so I think we need to meet half way here. Can you give me some pointers 
> to where and how an SCM would be hooked in?

For the buckminster case we'd have very few configuration options (no 
urls or anything) which is good.
Hudson expects an SCM plugin to behave like that:

let hudson know if the SCM supports polling, if a workspace is necessary 
for polling and if polling is supported, determine if there have been 
changes since the last build that would require an update/check-out. In 
easiest case we could simply not support polling.

If there are changes, or polling is unsupported, hudson will ask to SCM 
plugin to populate the workspace and passes the configuration of the 
form your plugin added to the job configuration.
In buckminster case this would be a list of cquerys or mspecs I'd say.

If an update can be implemented in favor of a 'replace', the plugin 
should gather the changes (which files, comment, author, time, 
action,...) and persist those into a file changelog.xml which will be 
evaluated by hudson to present it to the user.

Optionally an scm plugin could also offer a repository viewer if the SCM 
system supports that (like the web viewer for SVN + Apache). The user 
would use that feature to click on entries in the change log. This would 
be rather difficult for a buckminster meta-scm since there might be 
different systems involved, but I don't think it's that important.

So yes, I'm pretty sure I could implement something like that in hudson 
if only there are ways to have buckminster update things and tell me 
about the changes.

In fact this approach would be quite appealing since there'd be almost 
no configuration effort in hudson, just query what you want and have 
buckminster worry about how to get that.

One thing I don't like too much though, I hate leaking SCM credentials 
in a resource map. It should be possible to write a buckminster 
extension that accepts credentials with the setpref commands, right? If 
so (and if we can solve the other issues), I'd rather code this logic 
into the hudson plugin. Credentials for repositories are entered into 
the global hudson configuration and the plugin sets the credentials 
silently with 'setpref' before executing the actual 'resolve' the user 
wanted.

Best regards,
Johannes