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

Thomas Hallgren schrieb:
Johannes Utzig wrote:

... how to make buckminster behave well as a 'meta scm' for hudson? How to force an update on every build, how to retrieve the commit logs? If you show me the way , I'll do my best to implement the dirty little details.

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?

I know you said that the check-out is made before the build, but perhaps this could be set up as two builds? The first would just produce a list of things to check-out/update and Hudson would uses that the second. The way to accomplish that would be to run a buckminster import that just produces a BOM (no materialization), then extract the relevant SCM entries from the BOM and feed that list to Hudson.

Regards,
Thomas Hallgren

The Hudson philosophy (for a freestyle project) is fairly simple.
A job uses 0 to 1 SCM plugins that can be configured in the job configuration to check out things into the job's workspace.

After that 0 to n build steps are performed on that workspace.

Once the build is done 0 to n publishers can be invoked that do stuff like gathering test result, checking for TODOs in the source code, and so on.

So hooking up a new SCM plugin is fairly simple from what I know. You write a plugin, add some configuration settings and are free to execute code. I could try doing that if I'd know how to force update behavior and which part of buckminster I'd have to patch to be able to receive the change logs. For a proof of concept however, it might be sufficient to force a replace and ignore the commit logs. That would result in the required behavior and the rest could be added later.

The bom idea would IMO not work because the existing SCM plugins are meant to be configured in the job configuration (i.e. which modules they should check out for the job). I don't think it really fits into the concept to have a pre-scm step that actually changes the job configuration for the scm plugin that's invoked after. More so: I don't think it's currently even possible to check out stuff from let's say both CVS and SVN for the same job. With a completely new job kind specific to buckminster projects it might be possible to create a bom and feed SCM plugins from that, but that's beyond my so far gathered hudson-knowledge and would be more of a long term goal.

Best regards,
Johannes


Back to the top