Blue Prints‎ > ‎

Pre-tested Commits in Hg Plugin

Pretested Commits is one of the most wanted features in the Jenkins CI OSS. This feature is already implemented for Subversion, Github and ClearCase UCM, but it remains to be implemented for Mercurial (Hg).

User Scenario

When a developer wants to integrate code into the main, default or trunk branch oh the VCS, he or she must make sure, that the contribution has the requested quality before committing it. If it breaks the build, the main branch is rendered useless for his colleagues. The error will eclipse all other potential errors until it's fixed - most teams will therefore not allow contributions to the trunk before the broken build is fixed. Development is on pause!

Therefore the integration branch should never break.

A simple way to achieve this is to implement a resemblance the approach of the benevolent dictator and his lieutenants, which is quite common among OSS communities. The concept is that they guard the core of an OSS repository. Peer contributors don't even have write access to this repo. They can fork or clone from it and then only make their contributions by example. When they are ready, they make a pull-request to the core committers - the dictator and his lieutenants. ONe of the core committers will pull and merge in the commit - and perform the necessary quality assessment. If it passes the pull request is accepted and committed, but it it fails - it's simply rejected.

Using this approach the integration branch of a well-managed OSS repo never breaks.

This same approach is implemented in some of the SCM plugins in Jenkins CI - where Jenkins then becomes the benevolent dictator.

But it is still needed it in the Mercurial plugin 

Design Proposal

We suggest that the current Mercurial plugin for jenkinc CI is extended with this new feature, that enables it to poll child branches (or local clones) and when new commits exists simply merge them into the build's workspace before the build phase is executed. After the build phase, the post build phase will take the responsibility for either doing a commit or a rejection of the merge.

This is how we implemented it in ClearCase UCM. and also the way the Subversion plugin implements it. The thing is, that this approach requires that the SCM plugin gets a foot-print  in the post-build step of a Jenkins job, which requires it to extend the Notifier extension point. This a kind of a mess and ideally the SCM extension should be added a wrap-up method (see The implementation itself has - due to the split between the pre-build step and the post-build step some resemblance to a co-routine. To implement a happy-day scenario is fairly uncomplicated. The make the plugin resilient to all possibly imaginary fault states is ...slightly more complex.


We estimate that students that are unfamiliar with Mercurial and Jenkins CI would spend 3-500 hrs on an assignment like this.

A professional implementation done by Praqma is estimated to 50 hrs.


This assignment is not startet - it's up for grabs.



Call Lars on +45 30 87 25 30 or mail to him on if you are interested in this Blue Print.