If you like us use Mercurial for your source control and use Jenkins for continous integration and deployment, there is something you should know. We use Mercurial tags to designate revisions suitable for some practical purposes. For example, we use tag 'qa' to mark a version of the system, which we think is worth deploying into our testing environment and running exetended set of tests. We also have a bunch of jobs on Jenkins, which are supposed to get latest 'qa' revision, build and deploy the system to testing environment.
Theoretical setup looks like following:
And one would think that since Mercurial's -r parameters work equally well with branches and tags, he is all set. And we apparently thought so.
Unfortunately, Mercurial's approach to tags and Jenkins' approach to checking for changes in repositories do not let the magic happen:
- Tags in Mercurial are merely records in a version controlled file .hg/hgtags. So in order to see moved tag you have to have this file in local repository.
- Jenkins uses a variation of hg incoming -r 'tag' to check for changes in repository. However, since in local .hg/hgtags tag points to the "old" revision, it thinks nothing has changed for that tag-branch.
Jenkins developers already know about this issue: Support tags instead of branches
Simple (although not excatly most efficient) trick that works is wiping the workspace before build. There is a plugin, which can make this a part of a build job: Workspace Cleanup Plugin. Do not forget to mark this checkbox in job configuration:
This solutions has an obvious drawback of discarding any artifacts from previous build, which might save time during the next build and cloning the entire repository from the source control each time instead of just a bunch of changes.
For us I figured we are not running these 'qa' builds too often and the codebase is not too big yet, so we've settled with this workaround for the time being.