| Approach for splitting Buckminster jobs in Hudson [message #649876] |
Thu, 20 January 2011 20:07  |
 Axel Guckelsberger
Messages: 354
Registered: July 2009 |
Senior Member |
|
|
Hi all,
I want to ask for best practices for using multiple Hudson jobs with
Buckminster in order to divide a comprehensive build system into smaller
pieces.
The intention behind this is to get still quick feedback also if the whole
process takes a good while (which is not difficult with an increasing amount
of included bundles).
As my project is primarily based on EMF it would not make that much sense to
split it into several modules. In practice a meta model amendment usually
affects almost all parts of the application. Therefore I decided to split
the process by its stages (preparation, tests, build, tests, deployment, and
so on).
My confusion relates to the relationship between the Buckminster import
command and reusing artifacts from previous build jobs. The more I am
working on the interplay between the different jobs the more complicated it
seems to become.
At the moment my basic setup is as follows (leaving out non-relevant parts):
- Job A: create and publish the target platform (used by the Buckminster
Hudson plugin)
- Job B: checkout all sources from SVN with Hudson; use a "special" headless
Buckminster installation to import the cquery (rmap pointing to local
reader) and generate EMF and GMF bundles from corresponding models. Each
generated plugin bundle is packed to a tar file which is archived as
artifact. Dependent jobs which might need for example the meta model plugin
can then fetch it as desired. All other jobs use the "normal" headless
Buckminster because the "special" one incorporates unwanted UI stuff due to
GMF dependencies (see 315183 and 315247 for more information).
- Job C: checkout all sources from SVN with Hudson again; use build step
'Copy artifacts from another project' made available by the Copy Artifact
Plugin to fetch the tar files from Job B, too; extract and sort in these
files; create a tar of everything as output and archive this one for Clone
Workspace SCM; this is intended as the base for all further jobs which need
the 'full source' (manual + generated code).
- Job D, E, F, etc.: get tar with all sources by using the Clone Workspace
SCM plugin as build trigger; do something with it, for example unit testing,
code coverage and building a p2 repository for the rcp product.
The tar file in job C is used because the Clone Workspace SCM plugin does
not consider hidden files (like .buckminster or .metadata).
Jobs D, E, F, and so on all have some shell-based cleanup actions before the
actual Buckminster script:
rm -Rf $WORKSPACE/.metadata
rm -Rf $WORKSPACE/features
rm -Rf $WORKSPACE/plugins
rm -Rf $WORKSPACE/buckminster.output
rm -Rf $WORKSPACE/buckminster.temp
tar xvf output.tar
My questions regarding this are as follows:
* Each job must perform the import command. This seems to cause problems
with the target platform (see below). Do you have any idea how to avoid or
repair this behaviour?
INFO: import '-P' 'com.example.build/buckminster.properties'
'com.example.build/build/test.cquery'
INFO: Resetting target platform Buckminster Default TP
ERROR [0001] : Resource '/.buckminster/tp' is not local.
I saw that some other projects use the setpref command before doing the
import to define a specific targetPlatformPath, but I guess this is already
handled by the Buckminster Hudson plugin, isn't it?
* Is there an easier way to let Buckminster (re-)recognize the workspace
bundles, ideally without pointing all jobs to the same physical workspace
folder? Maybe I am overseeing something obvious.
I already thought about introducing something like a staging repository,
so that the generated bundles could be commited which could then trigger the
subsequent builds. But this would create new difficulties and potential
problems.
But could it be that the Copy Workspace SCM functionality is a
completely wrong approach? One alternative would be to use the SVN
repository in all jobs and fetch only the generated bundles (from job B) in
addition.
Thank you for reading this far. Any helpful pointers are highly appreciated.
Regards,
Axel
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02124 seconds
] 
Search
Help
Register
Login
Home
