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 Thomas,

comments inline

Thomas Hallgren schrieb:
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.

Yeah, polling really is no big deal at first. I'm not even sure if it makes much sense for buckminster since you'd have to poll possibly many different kinds of source repositories.


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.

As long as you think it's possible. I'll have a look at the implementation to get an impression on how big the changes would have to be. Might take a few days though until I can get to that, though.


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.

A viewer is a very optional thing, like the polling, I only mentioned it to sum up how things currently work in hudson (to the best I know). I mean, it could be kinda nice to have the svn repository url together with the change logs, but it's really not that important I think. Besides, the viewer is also out of scope for hudson itself, I think it's meant to be just a link to for example the webfrontend of e.g SVN.


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?

Yes, that's exactly what I meant. Some way to tell buckminster "do a cvs/svn update on the stuff that was previously resolved into this workspace and tell me what happened meanwhile". I think that could also make sense for regular buckminster usage from within eclipse. Re-run a cquery/mspec and have the option of fetching updates from the SCM on the way (not the default option though, but it would be a nice quick way to get up to date with two clicks).


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


I don't think that matters at all. Let's say a maven artifact got updated. I wouldn't expect to see an actual SCM change log for that. The change log is interesting for CI because of the automated unit testing. Out of a sudden one of your tests fails. You click on the build that failed, click on the change log in hudson and see 'ah, developer XY changed the class that failed in the test-runs since the last build' and you know immediately what's wrong with your build. The other cool thing about the change log is reporting. I think most companies have some kind of naming scheme for commit comment on fixed bugs. You can parse the log entries for something like [BUG#12345] and automatically generate change logs from that to let people know what has been improved from 1.0.0 to 1.0.1.
Binary artifacts don't count for much there because
1. you usually don't add a comment to whatever artifact repository you are using when you deploy a new version, so what information would you expect to see there 2. binary artifacts are out of scope for unit testing (they'd only matter for integration tests).


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


This sounds perfectly fine to me, simple properties would be the easiest way to get the desired behaviour.

This could really be a very cool feature and with hudson getting the most popular CI server on the market, I'm sure tight integration can be a boost for buckminster's popularity (just think of the cool demos you could do with that :) ). However, it looks like there's still a bit to do before we got all the pieces together, but an RCP build tutorial + CI system integration could be done much earlier already, even though without the cool meta-scm feature.

So how would you like it to look like?
Since you'd like to see buckminster do the actual checkout, the workspace needs to be cleaned up on every build. Therefore the first hudson build step would be a shell invokation that wipes the hudson workspace.
The next build step will invoke buckminster and place 4 commands:
1. passes an mspec to materialize the target platform for the MailApp. similar to what you've shown me, right? 2. The 2nd will be setPref to set the target platform location to the newly created one 3. The next command will be resolve mailapp.product.feature to do the checkout from svn 4. the last command will be a mailapp.product.feature#create.product.zip to build the actual RCP with the ant script from the patch submitted to bugzilla.

Does that sound ok to you? If the patch is ok to you we'd only need the rmap, cquery and mspec then. I'm not too familiar with the mspecs yet because I could find virtually no documentation for their usage except for the schema, but I'll I'll do my best to deliver those three pieces within the next days.


Best regards,
Johannes


Back to the top