Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: layout fix


The change was necessary in order to support the new Pipeline job types and requires you to migrate your job configuration.


Migration guide from 2.x to 3.x




If you’re using Job DSL to generate your jobs this is an easy fix. Just update your Job DSL script with the new syntax, which is show in the JobDSL example section below.

Manual created jobs


If you’re creating your jobs manually, you’ll need to manually reconfigure your jobs.


When updating the plugin your current configuration will not show so you need to know how your jobs was configured and make the analogue configuration as Git Plugin extension.


Example below in the pictures.

The names of the fields have not changed and the strategies remain unchanged as well.


Additional behaviours → “Use pretested integration” -> Configure Integration branch and repository


Who should upgrade and who should not


  • Users who rely on Multiple SCM plugin should not upgrade to 3.x since we’ve removed support for this plugin in 3.0.0.  If you use this plugin, consider moving to the Pipeline job type instead and leave the deprecated MultiSCM behind.
  • If you use purely FreeStyle jobs in your environment, upgrading to 3.0.0 is recommended. It won't provide any benefits and won’t be strictly necessary, but we recommend to follow along and if you have many manual configured job, take the opportunity to script them using Job DSL or Jenkins Pipeline syntax.
  • If you use Matrix job, you can benefit from version 3.x as the post build step is now optional and thus gives you flexibility to use pretested integration in a Matrix job setup.


Comments and discussions on this page is not noticed.

Plugin configuration


Tips for matrix job configuration


When you use the Matrix Job type, the merge is performed for each child job in your matrix and even thought the Pretested Integration Plugin post-build step is added we make sure it is only executed once in the parent job. This ensures that we only attempt to remove the branch once during a Matrix build after all childs have completed and have completed successfully.


We assume that your integration process using Pretested Integration Plugin is serialized so only one of this kind of job pr. project is building at the time. Else you're not sure the child jobs are integrating and verifying the same changes.

Manual building


 In In general you are not able to use 'Build now' with a Pretested Integration Plugin job configuration. The Pretested Integration Plugin is first in action when a "workspace" is handed over from the Git Plugin it will when manually building 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:


  • If last build failed, thus the integration failed, for a non-persistent error (disk problem, licensing problem ...) rebuilding the job can succeed if no other build have been executed since last time.

  • If you have done a job configuration change, and need to trigger the job to test the configuration you typically need to make a commit that triggers the job. Push a commit to a ready branch, or wait for one.

  • There is a work around, that often enables you to build manually: Make the job parametrized with BRANCH_TO_BUILD and use that variable in the 'branch specifier'. Make BRANCH_TO_BUILD have the default ready-branch specifier, so if not given the job works as if there were no parameters. If you now build the job manually, you can type in a branch to build.



 Failed and ‘Nothing to do’ statuses when merging


The ‘Nothing to do’ build status is added to your build description in the following scenarios


  • Pushing a development branch that has no changes (result of merge is empty)

  • Using the plugin in a setup with more than 1 remote configured where the build is triggered by repository that does not have pretested integration plugin configured.


Failed builds can happen if there is a merge conflict which cannot be solved by a merge. In this scenario it is up to the user to merge the integration branch into their own development branch to fix their issues and deliver it again.


We tried to gather some common errors and problems seen, together with some suggested solutions but not much have been contributed. See Help and error messages

Scripted job examples

The following are examples on how to script jobs using this plugin. Refer to either the pipeline script generator in Jenkins or Job DSL API viewer for all the details.


Code Block
job("pretested-integration-plugin_our-integration-job") {
  scm {
     git {
          remote {
          extensions {
  publishers {


Scriptet  Scriptet pipeline



Example integrating the plugin repository itself using our recommended default configuration