Skip to main content

[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 Johannes,
Answers inline.

Johannes Utzig wrote:
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.

I think polling can be supported later. Let's start without.

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.

Yes, that sounds reasonable.

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.

This should be added to the CVS and SVN providers in Buckminster. It cannot currently handle that.

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.

Perhaps we can use change-log entries that will tell Buckminster how to redirect to a proper viewer. The viewer as such is of course beyond Buckminsters scope.

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.

OK, so I read this to mean that if a buckminster query is re-run on a workspace, it should have the ability to update that workspace and collect a change-log of the updated entries. That log must then be available (using some command) so that Hudson can obtain it. Does that sound OK?

One question here is how to handle things that are not source (binaries imported to the project or added to the target platform).

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.

I agree. This is something that needs to be resolved in a much better way. A first cut could simply pass credentials on the command line (using -Dsvn.user=xxx -Dsvn.pass=yyy). A corresponding RMAP entry can then look like this:

<uri format="svn+ssh://{0}:{1}@oursvn/path/trunk/{2}">
  <bc:propertyRef key="svn.user" />
  <bc:propertyRef key="svn.pass" />
  <bc:propertyRef key="buckminster.component" />
</uri>

- thomas


Back to the top