After recently doing some work on/with the vRealize Automation plugin for Jenkins, I got to thinking about doing the reverse of what it does and publishing Jenkins projects in vRA using XaaS. So, I’ve put together a vRO package to support this. The plugin will support builds that don’t have any parameters, as well as ones with (simple) parameters.

Part of the thinking here is some folks want to leverage already existing Jenkins projects with the vRA Jenkins plugin, but then also want to be able to do Day 2 operations. Rather than having them log into both interfaces, this provides a way to call the Jenkins project and handle Day 2 ops from the same interface. This set of workflows also supports the use of multiple Jenkins instances through the use of the REST host name as a parameter, while also having an option for a default host to use if one is not specified as a parameter.

The package file containing the workflows is available here. Or if you’re using vRealize Lifecycle Manager you should be able to add it as content and pull it from the GitLab repo ( https://gitlab.com/vcaptain/jenkins-vro).

The rest of this is going to be a walk-through of setting up a target host and a couple of examples using it.

Set Up

There are two workflows for setting up the REST Operations. One (add Jenkins Rest Operations) just creates the operations on an already existing RESTHost. The other (Add a Jenkins REST host and Operations) creates the RESTHost prior to adding the operations.

Once the operations have been added to a host you should see something similar to the image below in the vRO inventory.

Setting the default host

There are two ways of setting the default host for the Jenkins workflows. One is to use the workflow in the package called “Set Default Jenkins Rest Host.” The other option is to simply edit the configuration item shown below.

Jenkins project without parameters

First, we’ll look at a Jenkins project that doesn’t use any parameters (in a subfolder: using the Folders plugin). In this case there’s a project called ‘REST_NO_PARAMS’ in the folder/subfolder (folder1/subfolder).

Looking at the actual project which is configured as a Freestyle Project we can see that for purposes of our demo this is very simple in that it only runs a shell command to print out environment variables.

Setting up the XaaS form

To create the XaaS blueprint choose the “Jenkins – Run Build (No Params) workflow as shown below. This workflow takes two arguments: the name of the of Jenkins item (With path if it’s in a folder) and the name of the RESTHost. Based on our example above we’ll use ‘Jenkins-01‘ as the RESTHost name and ‘/folder1/subfolder/REST_NO_PARAMS’ as the job name.

Click Next to get to the General tab

With XaaS forms, you can choose to make the field values visible or not, read-only or not etc. In this case I’ll make both the jenkinsJobName and restHostName fields visible but Read-Only with a predefined value.

The completed form looks like this.

Press Next, and because this workflow doesn’t provision anything we’ll choose ‘no provisioning’ on the subsequent screen.

There isn’t an associated update workflow and you can choose whether to assign it to a category or not.

The blueprint then needs to be published and added to your catalog.

Requesting the Catalog Item

Now we’ll request the catalog item. (These screenshots are taken using vRealize Automation 7.5 but all of these workflows have also been tested with 7.4)

Once submitted we’ll see the request finish successfully.

Jenkins project with parameters

For this example we’ll use a another freestyle project (/folder1/subfolder/REST_WITH_PARAMS) that has four parameters associated with it: two string, one choice and one boolean.

Setting up the XaaS form

In vRA we’ll create a new XaaS blueprint. Start by selecting the workflow (Jenkins – Run Build with Params from XaaS Form).

The form will initially display three fields to start with. Two of those will be the same as the No Params version: jobname and restHostName. In addition there’s a “prefix” field. This field will help the vRO workflow determine which fields in the payload to pass as parameters to Jenkins (we’ll use ‘vcaptain.pass’).To successfully call the Jenkins project as shown above, we’ll need to add four fields to the form to match the parameters the job expects. To pass the parameter values through we’ll add the prefix to the parameter names. (Ex: the parameter STRINGPARAM1 in our Jenkins project becomes the label vcaptain.pass.STRINGPARAM1 in the XaaS form)

The form will now look something like the image below.

Now we’ll need to add the four fields for the Jenkins project parameters. STRINGPARAM1 and STRINGPARAM2 will simply be text fields, CHOICEPARAM will be set up as a drop-down, and BOOLEANPARAM will be set up as a CheckBox field

Setting up STRINGPARAM1