Itest & Remote invocation of parametrized & tokenized builds with Hudson CI
In one of my previous projects I was asked to setup the environment / automate integration tests (Referred to as Itest from now on) which required a machine with 2 CPU's & 5 GB RAM, this means that in any case a developer wishing to run Itests will never be able to run them locally, and will have to use some existing server.
The problem with my previous statement is that the developer, whilst checking his tests will be busy most of the time preparing his Itest environment, rather then checking the integrity of his tests, need I say that the fact we need 2 CPU's & 5GB RAM means the server takes time to load and only once it is up you can start testing.
From a Continues Integration point of view, these tests should run as part of the Nightly build, automatically & with no user intervention and of course the running server should be using the latest tests from SCM.
The big question was: how do we achieve all of the above with one Maven Project one Job in Hudson-CI and reuse this code as a Maven module for every new scenario we are testing?
Hudson, Maven & some Groovy on top (or beneath in order to be accurate):
- Hudson - a built in mechanism of Tokenized builds & parametrized builds which can be invoked by browsing a url
- Maven - or any other build tool for that matter can invoke a Hudson url
- Groovy - the logic of build invocation is performed by Maven Groovy Plugin - this is what the client choose, and did most of the writing.
OK so how does this all come together?
On the Maven side / Developer's side there is a "skeleton" parent pom with some Groovy logic (I will ask clients permission to attach the code to this post) of how to build the hudson url & pass the token's.
Parent pom includes Groovy logic which uses the a url.toURL method whilst passing a token and a parameter to hudson, a time to wait period which waits until we receive "Build Successful" from Hudson and fail after a set period of time (or it will run for ever ...) - parent pom is not to invoke any build but is there so its modules will inherit the url construction logic.
Maven module X has parameters therefore executes the constructed Hudsonurl + Hudsontoken + Jobparam, so does Maven module Y & Z etc etc ...
- A slave machine dedicated for Itest / a slave capable & available of running the Itest job - how to set up will be posted in a separate post
- A valid url Token, so it can only be invoked by people / code who "know" the Token
- A Parameter which is passed to Hudson Build step
- Token option is available only when running from within a servlet container if your test driving this with java -jar this option will not be available!.
- The defualt value of "default" is there so when hudson runs with no parameter this value will take presence if ot is not there build will not be able to run!.
In a freestyle project the build can look like this (for win / linux):
Future Enhancements (might need to add in the future):
As this project involves and there are more and more developers we will need more than one continues integration machine, and we do not want to start specifying the name of the machine inside the project's pom or we will find ourselves editing the pom several times a week.
A Hudson built in solution would be to tie the job to a Group of Nodes rather than a specific Slave Hostname, and add a few machines to that group this will result in the ability to invoke multiple jobs simultaneously.