[
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