In the previous post I showed how to use the Parameterized Trigger Plugin to pass information be parts of a build chain. But what about between completely independent chains? That’s pretty important too. (And easy if you were I not also learning about Mercurial at the same time.)

Before we get into the actual details of the solution, let’s look at a ‘typical’ delivery pipeline. (Where typical is how I think of things.)

  • Commit phase
    • Unit tests
    • Deploy to automation environment
    • Run the ‘shallow’ ui scripts
  • [Regression Automation] Security blanket phase
  • Deploy to manual testing environment
  • Deploy to staging environment
  • Deploy to production

Here we have five phases with some phases having multiple steps. (And potentially sub-steps as well.) Each of these is a distinct job chain and so we have to be able to it what to actually manipulate/interact-with during the chain. For all but the first chain the answer is in Tags which add some steps to our chain.

  • Commit phase – triggered on change to tip/trunk/head
    • Unit tests
    • Deploy to automation environment
    • Run the ‘shallow’ ui scripts
    • On successful run, tag with COMMIT_CLEAN
  • [Regression Automation] Security blanket phase – scheduled build from COMMIT_CLEAN
    • On successful run, tag with BLANKET_CLEAN
  • Deploy to manual testing environment – manual build from BLANKET_CLEAN
    • On successful run, tag with IN_TEST
  • Deploy to staging environment – manual build from IN_TEST
    • On successful run, tag with IN_STAGING
  • Deploy to production – manual build from IN_STAGING
    • On successful run, tag with IN_PRODUCTION

As mentioned above, if I was [smart] using svn rather than hg I could use the Subversion Tagging Plugin, but I’m not so it is a bit more complex.

Tags in Mercurial at associated with a particular changeset and stored in a .hgtags file. Which of course when it is updated via an hg tag command itself generated a changeset. If you are working in the ‘main’ repo, then this happens implicitly in the background. However, inside Jenkins you are not so you need to push the changes to the repo. Things get more complicated if however you are using the hg serve command which doesn’t support push out of the box since it is no-ssl. Following this however will enable it for things like just mucking about with getting the plumbing all wired up.

To do the actual tagging of the run revision you need to add another Execute shell build step.

<pre lang="bash">hg tag -f -r $HG_REVISION COMMIT_CLEAN
hg push

Note that I did not include it in the same step. This way if the first step fails to completely cleanly the job fails and does not continue to this step which means the tag doesn’t move.

(And yes, I know about the Promoted Builds Plugin but I’d like the label to go into the repo with the actual code and not just be contained in the CI tool.)