Question

We've got a few applications which is "managed" by a Mercurial repository. We build releases using Jenkins.

Once Jenkins has built a release we release it and go on working with new features. However, we don't have a specific way of keeping track of which revision we release. We can certainly figure it out, but it takes a little work to get it done.

If something goes wrong with any given release and wee need to find the release which fails, and there's a lot of "backtracking" required. We can't simply fix the bug in "head/trunk" of the repository, because we might have introduced new features. What we want is a way to quickly get the release we distributed, fix the bug there, and release it again.

Is there a "best practise" for this? Would a good way be to have Jenkins to tag the revision it is doing its build on?

Was it helpful?

Solution

The mercurial plugin for jenkins makes the MERCURIAL_REVISION and MERCURIAL_REVISION_NUMBER variable available to your build scripts. If you include this number in your release, either in a (separate) file or compiled into the program and accessible on the about screen or some other place you should be able to use this number to find the right version of your code.

Also see How to get revision number from Mercurial repository and paste it to NetBeans resource bundle? for tips on getting more info than a single revision number from mercurial.

UPDATE: How to include the revision in your code is dependent on the programming language, compiler and the type of build language you use.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top