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 29 Next »

Plugin Information

View Inedo BuildMaster Plugin on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

This plugin integrates Inedo BuildMaster to Jenkins allowing Jenkins jobs to gather version information from BuildMaster and trigger builds on an application.


Note: A minimum BuildMaster version of 5.5.0 is required for this plugin

First, you need to ensure that an api key as been configured in BuildMaster at BuildMaster > Administration > Api Keys & Access Logs.  Without this the plugin won't be able access BuildMaster.  Ensure that the following items are checked:

  • Native API
  • Variables management
  • Release & package deployment:

Next, you need to go to Jenkins' system config screen to tell Jenkins where's your BuildMaster resides.  I have found that I need to configure it for NTLM authentication on our network otherwise my account gets locked out.  Clicking the "Test Connection" button a few times will confirm whether this is required or not.

Lastly, you need to add a couple of steps to your Jenkins job.  Because the Release and Build numbers could be required by several build and post-build actions selecting the application and has been separated from the trigger build action.

The "Select BuildMaster Application" build envrionment setting allows you to select the the BuildMaster application you are dealing with and the settings will be used to inject these environment variables into the job at build time:


Ignore the Deployable option for the moment, that will be covered in the advanced topics section later in this document.

The "Create BuildMaster Package" action can be added as either a build step or post build action.  The choice of which to use will be largely dependent on how you import the build artifacts into BuildMaster and your personal preference:

  1. You are using the BuildMaster Jenkins Build Importer Build Step which imports build artifacts from Jenkins: the post build action is required
  2. You are using a standard BuildMaster build step and importing files from a folder that you've placed the artifacts into from the Jenkins build (eg using ArtifactDeployer Plugin): either the post build or build step actions will be fine
  3. You use an external artifact repository such as Nexus or Artifactory: either the post build or build step actions will be fine

If you haven't used the "Select BuildMaster Application" action then you will need to go into the advanced section and set the application id, release and build number details.

To deploy the build to the first environment ensure that you have the post-build step action "Auto-Promote Build to the Next Environment" set in BuildMaster.

The "Deploy BuildMaster Package To Stage" action can be used to deploy (or re-deploy) a package to a specified stage by specifying a Stage Name, or deploy to the next stage in the pipeline by leaving Stage Name empty.

Pipeline Script Support

Declarative pipeline example

pipeline {
  agent any
  environment {
 // Prevents echo statement from breaking if packageNumberSource not supplied in
 // buildMasterWithApplicationRelease step below leaving BUILDMASTER_PACKAGE_NUMBER
 // variable undefined
  stages {
    stage('Main') {
      steps {
        buildMasterWithApplicationRelease(applicationId: '1', packageNumberSource: 'BUILDMASTER') {
            echo """
       Application id = $BUILDMASTER_APPLICATION_ID
            // Jenkins declarative pipeline script has a somewhat restricted syntax.  Unfortunately to return package 
            // number you need to wrap this in a script block
            // See:
            script {
                BUILDMASTER_PACKAGE_NUMBER = buildMasterCreatePackage(applicationId: BUILDMASTER_APPLICATION_ID, releaseNumber: BUILDMASTER_RELEASE_NUMBER, packageNumber: BUILDMASTER_PACKAGE_NUMBER, deployToFirstStage: true, waitTillBuildCompleted: [printLogOnFailure: true])
            buildMasterDeployPackageToStage(stage: 'Integration', applicationId: BUILDMASTER_APPLICATION_ID, releaseNumber: BUILDMASTER_RELEASE_NUMBER, packageNumber: BUILDMASTER_PACKAGE_NUMBER, waitTillBuildCompleted: [printLogOnFailure: true])
            echo "Redeploy to Integration"
            buildMasterDeployPackageToStage(stage: 'Integration', applicationId: BUILDMASTER_APPLICATION_ID, releaseNumber: BUILDMASTER_RELEASE_NUMBER, packageNumber: BUILDMASTER_PACKAGE_NUMBER, waitTillBuildCompleted: [printLogOnFailure: true])

Scripted pipeline example

node {
    buildMasterWithApplicationRelease(applicationId: '1', packageNumberSource: 'BUILDMASTER') {
  echo """
  buildMasterDeployPackageToStage(applicationId: BUILDMASTER_APPLICATION_ID, releaseNumber: BUILDMASTER_RELEASE_NUMBER, packageNumber: BUILDMASTER_PACKAGE_NUMBER, waitTillBuildCompleted: [printLogOnFailure: true])

Advanced Topics

Multiple Jenkins Jobs Pointing At A Single BuildMaster Application

If you have multiple Jenkins jobs all triggering a build for the same BuildMaster application it is vital that you use the "Select BuildMaster Application" build step as this this build step will queue any jobs attempting to run for the same BuildMaster application while another is already running so that you cannot get two jobs triggering a build in BuildMaster at the same time.

The following two options have been supplied as a means to ensure that the triggered BuildMaster build picks up artifacts from only the Jenkins jobs that have build for its release:

  1. "Enable Deployable in BuildMaster": selectively enables deployables for a release
    1. In BuildMaster you must ensure that Deployables are disabled by default for a release
    2. The "Select BuildMaster Application" Deployable option must be set to the correct deployable
  2. "Copy Previous Build's Variables": if checked will gather the variables from the previous build and add them to the list of variables being passed in for this build, overriding any that are being set for this build.
    1. This could be useful if you're only passing in pointers to a version, eg you keep your artficats in Artifactory or Nexus
Artifactory Integration

BuildMaster already has an Artifactory Extension, but I have also developed a BuildMaster Artifactory Variable Extension to assist with referencing artifacts from Artifactory and cleaning up unwanted artifacts which works very nicely with the "Set Build Variable in BuildMaster" option.



Version 2.0 (July 29, 2018)


  • This version of the plugin is not backwards compatible as it has gone under a complete rewrite to:
    • Move away from the BuildMaster Native APIs to the Release & Package Deployment APIs where possible
    • Add Pipeline script support

This has only been tested with BuildMaster 6, but should work against BuildMaster 5.5+ 

Version 1.6 (Nov 14, 2016)
  • Prevent caching of requests
Version 1.5 (Nov 14, 2016)
  • Deploy to stage build step
Version 1.4 (Oct 19, 2016)
  • Support BuildMaster 5.5.0
Version 1.3 (May 15, 2015)
  • Expand variable values defined in “Set Build Variables in BuildMaster” property
  • Queue Jenkins builds targeting same BuildMaster application
Version 1.2 (May 14, 2015)
  • Create Build waits for previous execution on BuildMaster to finish before new one is requested
  • Improved wait for build to complete handling
  • Create Build request triggers build regardless of whether BuildMaster application has build step or not
Version 1.0 (May 1, 2015)
  • Initial Release
  • No labels