Back to Top

Choosing a specific Jenkins Build with BuildMaster

BuildMaster is an Application Release Automation tool. In this tutorial, we will demonstrate how to select a specific build in Jenkins, and pull a release package from that build.


Previously we ran through how to kick off a new build in Jenkins and then import that build into BuildMaster. This is the way most of our users integrate with Jenkins, or any CI engine with BuildMaster, however there is another feature that some users take advantage of.

In this tutorial, we’ll set up a new Pipeline for the application we’re pulling from Jenkins so that we can pick a specific past build to import.

You can download the sample Otterscript plan and JSON files used in this tutorial.

Step 1: Create a new Pipeline

BuildMaster allows, and encourages, users to create multiple pipelines for their applications to cover a host of release scenarios. We’ll name this pipeline, Import Specific Build, as well as give it a color to clearly identify it as a non-standard pipeline.

This new pipeline will mirror the standard pipeline stages of Import, Integration, Testing, and Production from the previous tutorial.

On that same note we’ll also use the same Deployment Plan for Integration, Testing, and Production. Of course we can also add any Gates and Event Listeners as needed.

Step 2: Create a Release Template

We’ll next set an application variable and use that variable in a Release Template, which will allow us to pick a specific build definition, and build number.

First, we'll set the application level variable. This variable will set $JenkinsProject to the specific Project in Jenkins we're working with. In this case, AccountsWeb. You set application variables under the settings tab.

We’ll then create our release template, name it, and set it to the new pipeline.

We'll add a Release Variable to pick which build we want. We'll name it JenkinsBuildNumber, and make sure that the value is required and limited to items in list. We'll choose Dynamic List (Jenkins Build Number), and set our credential and use the application variable ($JenkinsProject) for its value.

Also, we'll make sure that the value is required, and also limited to items in the list.

We now have a release template that, when used, will prompt us for a specific build number. Next, we'll use this in a new deployment plan.

Step 3: Create a new Deployment Plan

Even if we’re using a previously defined deployment plan to move the application through the new pipeline, we still need to import the build, and we need a new plan for that. We’ll name the plan Import Previous Build.

This new plan will start with a General block and short description, and then add two operations, Import Artifact from Jenkins, and Set Release Package Number. The first operation will let us select a build to import using our variables.

The second will let us set the package number. We'll use the $JenkinsBuildNumber variable so that the package number is the same as the build number.

Please note that if you choose to set the package number to the same number as the build in Jenkins you may also need to change the Package Number Scheme to Date-based (which can be found under advanced settings) in certain situations. This allows for a package name to be reused in the same release.

We will then save and assign this new plan to the Import stage of our pipeline, and select the stage to automatically promote to the next stage of the pipeline, Integration.

Step 4: Create a new Release

Now that the new pipeline, plan, and template are in order we can create a new release using them.

We’ll create a new release, and set the template and pipeline to Import Specific Build.

When we create our package another prompt will appear for the Build Number.

Once set, BuildMaster will then import the build number specified and the release package can be moved through the rest of the pipeline.