Developed by

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.

This plugin is developed by Praqma and sponsored by Atmel - It's maintained in the scope of Joint Open Source Roadmap Alliance (JOSRA).

The plugin rely on the SCM plugin to establish the workspace and then takes over to do the integration. Last the job make the decision whether to like and commit the result or hate and discard it. To get a comprehensive introduction to how the plugin relies on the SCM plugin please read the blog post at the JOSRA: Pretested Integration Plugin.


Support and contact

Please send us an email on support@praqma.net if you have a request or question regarding the plugin.

If you find an error or have feature requests, use the Jenkins issue tracker.

Comments and discussions on this page might not always be noticed.

The recommend setup and git workflow

Here is a simple git workflow where you can work on a features branch, and when ready push to a ready-branch. The Pretested Integration plugin, if configured as described will then pick up your changes, merge them and verify them. If verified they are integrated on the integration branch. The ready branch are automatically deleted if integration was successful.


The simple plugin configuration

To configure the plugin to pick up ready branches, verify them and deliver them to the integration branch use the following configuration:

Configure the SCM as above.

  • Recommend ready branch specifier is the 'Branch Speciifier' : ready/**
  • Remember to add the two additional behaviours to ensure a clean work space and that old deleted branches are cleaned
  • It is recommended to name your repository in the 'Name' field.

Configure the Pretested Integration plugin with integration branch 'master' and the named repository 'origin'.
There is a Pretested Integration plugin post-build step, which ensure verified changes are published. You don't have to configure it - it is automatically added.

Now you only need to configure your definition of done - the verification. How should the job verify the commits? It can be compile and measure compiler warning, build and run unit tests and check that coverage do not drop.

The simple Git workflow

Get your repository up to date:

git fetch --prune

git checkout master

git pull origin master

Create a feature- or development- or... branch

git checkout -b feat_1337-improved-login-screen

...work, stage and commit changes.

Then push changes to a ready branch, which is basically just a branch following a naming conventions for branches matching ready/**.

git push origin feat_1337-improved-login-screen:ready/feat_1337-improved-login-screen

The change will be picked up by the plugin if configured as shown in next section.

Help and error messages

*NOT YET DONE - work in progress* (We have gathered some common errors and problems seen, together with some suggested solutions - Help and error messages)

Manual building

In general you are not able to use 'Build now' with a pretested integration job configuration. The Pretested Integration Plugin is first in action when a "workspace" is handed over from the Git Plugin (or Multiple SCMs Plugin), and typically those will serve the last build revision again. If that succeeded last time, the revision is deleted after the integration and retrying the integration fails.

Some successful and failing cases using manual builds are:

You are welcome to contribute with ideas and use-cases for manual build and support for it on the roadmap in the Trello board.

Using multiple repository configurations

The plugin is designed to work on only one repository - as in you can only integrate on one repository pr. Jenkins job, but your Jenkins job can be used with multiple repositories for eg. checking out several repositories into a given folder structure you need for building the software. Though we consider this a work-around for not having the right dependency management, it can be done. You have the choice of using the Git Plugin or the Multiple SCMs Plugin, but need to follow the configuration examples below.

Requirements if using multiple repository jobs

Every repository should be explicitly and uniquely named* in the git repository configuration under 'Advanced'. Then use this as integration repository in the prested integration configuration

Example with multiple git repositories

  • The two repositories 'capital-letters' and 'numbers' are checked out to the same workspace.
  • 'numbers' are the repository that is being integrated, so the branch specifier will typically match that patter ('capital-letters' might just be needed for building)
  • The pretested integration configuration now explicitly states that the 'numbers' repository is the integration repository.
  • Also remember to add the two additional behaviours to ensure a clean work space and that old deleted branches are cleaned

Basically the same setup needs to be applied if using the Multiple SCMs plugin, but you can benefit from additional behaviours like checking each git repository out to a subdirectory if needed. Still every git repository must be explicitly and uniquely named.


Code contributions were initially made by Computer Science students at University of Copenhagen as part of a study project

Ronni Elken Lindsgaard
Alexander Winther Uldall
Esben Skaarup
Andreas Frisch



Version 2.2.3
Version 2.2.1
Version 2.2.0
Version 2.1.2:
Version 2.1.1:
Version 2.1.0:
Version 2.0:
Version 1.1:
Version 1.0: