[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: Tutorial for building an RCP from hudson
|
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