One of the most useful aspects of Jenkins, and one of the core for doing any sort of Continuous Delivery is chaining jobs. At its most basic, form, chaining jobs is easy-peasy; simply check the Build other projects and give it a list of jobs to to run.
But what if you have a very busy code repository? Suddenly your job chain is less likely to be the same reversion on all agents and your chain just got a bit more sophisticated. Luckily, the magic isn’t too too hard.
Enter the Parameterized Trigger Plugin. (So go install it now.)
Imagine we have a 3 step chain:
- On poll, run unit tests
- Deploy code to automation system
- Run automation ‘shallow’ scripts
Oh, and to make this interesting, I’ll use Mercurial.
The unit test job is is going to get trunk/head/tip/whatever so it is the simplest to configure — as there is no real configuration to do. The trick with this particular job is to share its knowledge of the world with later jobs. To do this we do not use the Build other projects Post-build action, but instead use the Trigger parameterized build on other projects one. Like the other one, it takes a list of job(s) to fire, but the difference here is that it passes in environment variables that the triggered jobs can use as part of their actions.
In my particular case, I am using a Predefined parameters of
$MERCURIAL_REVISION is a magic value inside Jenkins that holds the changeset value it got from the server. There is also $SVN_REVISION, etc. Triggered jobs from this one can now use $HG_REVISION as if it was a standard build environment variable. What this means is that the triggered job can be setup to pull from the Mercurial server in the ‘standard’ way, but can then have as a build step
hg up -r $HG_REVISION
It is not the most efficient thing but now our downstream jobs are going to have the same set of changes as the upstream ones. Which is exactly what we need for a proper job chain.
And then you just repeat for each job in the chain.