Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 51 Next »

Plugin Information

View Pretested Integration on the plugin site for more information.

Developed by

Code contribution by

Alexander Winther Uldall
Ronni Elken Lindsgaard
Esben Skaarup
Andreas Frisch

Sponsored by


The Pretested Integration Plugin offers a branchy approach to pretested integration (also known as pre-tested commits), which upholds the invariant; that for a specific branch, known as the integration branch, all commits have been verified.

The plugin delivers an API that makes it possible to easily provide pretested integration functionality for arbitrary scm tools which is capable of using branches or a similar technology.

This Plugin was originally intended to be a core plugin used by other plugins to support the branchy approach of pretested integration, but has of version 2.0 be switch to be THE plugin for all SCm tools. Right now supporting Git.

Find this plugin useful? Support further development with BTC 1PTthwWx4AaNLCLNNsJ8gDxhWoaQz1n64B

Setting up pretested integration with Mercurial

Development workflow

The workflow is adapted from the personal branch version of the branchy approach described in https://wiki.jenkins-ci.org/display/JENKINS/Designing+pre-tested+commit.

1. A named branch is used as the team integration branch (defaults to 'default'). 

2. The developer checks out a feature branch based on the integration branch and commits her changes. (hg update -C default && hg branch feature-branch)

3. Every team member has a designated staging branch (also a named branch) unto where she merges the changes and pushes this branch. (hg update stage-branch && merge feature-branch && hg commit -m "Finished development of feature")

4. Jenkins looks for changes on the stage branch, and integrates verified changes in the integration branch and pushes the updated branch.

Jenkins setup

For each staging branch, a Jenkins job is configured to poll for changes and trigger a build. A build is created for every found commit, and is sequentially merged into the integration branch if the commit is verified. 

Subsequent jobs should be configured by listening on the integration branch and commense further tests, deployment etc.

Job configuration

1. Under "Source Code Management" select Mercurial. For "Repository URL" use the repository url. Type in the name of the staging branch into "Branch".

2. Under Build Environment, check "Use pretested integration"

3. Select Mercurial and type in the name of the integration branch into "Integration branch".

_Note: A post-build action can also be configured, however it will automatically be activated by the plugin the first time a build is triggered._

Currently known issues

* Only builds with Result.STABLE is committed.

* It is not possible to customise the integration message

* If the integration branch does not exist, the plugin will fail.


Version 2.0:

  • Git integration is now supported

Version 1.1:

  • Dependency of Mercurial plugin set to 1.39 due to previous failure to trigger on merge commits
  • Removed UI elements that should not have been there

Version 1.0:

  • Release of the first stable version
  • No labels