How to Configure Jenkins Job with Runtime Parameters

There are two ways to pass parameters between two jobs. First method is to configure the parameters within first job. These variables are configured with hard-coded values.

The second method is configuring the job to accept parameters at runtime. It allows you to pass different value each time you run the job without making any change in the job configuration.

This article is a step by step approach on using the second method in Jenkins.

  1. Install Parameterized Trigger Plugin, if not already done.
  2. Create two jobs by name Project1 and Project2.
  3. Click on Project1 job and then click on Configure link in the left side.

  4. You’ll see a new option – This build is parameterized. Enable that option

  5. Now you need to select the type of parameter from the list of available parameters.

  6. I’ll select String Parameter and configure it.
  7. Specify the parameter name, default value and description.

  8. In this example, I’m passing SVN Revision number to the target job to check-out the code from.
  9. The parameter name is SVN_REVISION, default value is 124 and description to understand the job.
  10. We need to call the target job which will consume this parameter.
  11. Go to Build section and click on Add build step option.

  12. Select the option Trigger/call builds on other projects from the dropdown.

  13. Specify the name of the target job, it will be Project2 in this example.

  14. Pass the parameter we captured above, i.e. SVN_REVISION by selecting Current build parameters option.

  15. By doing this, variable name SVN_REVISION will be passed to Project2 with the value you provide at runtime.
  16. Click on Save to save the changes.
  17. Click on Project2 from Jenkins Dashboard.
  18. You’ll see a new option on the left side Build with Parameters.
  19. Click on that option and you’ll be prompted to pass value.

  20. If you don’t provide any value, then 123 will be passed to the target job.

Continue reading


Configure Role Strategy Plugin in Jenkins

Allow me start the discussion by stating a real world problem, OR I must say a real world need. Most of the times, we have multiple teams working on different projects. As a matter of security, we don’t want any team peeps in someone else’s projects.
If you’re using Jenkins for your build promotions, you would certainly need to isolate various teams working on different projects. It is obvious that you cannot setup multiple Jenkins instances dedicated to each team. All of the projects will be configured in Jenkins as multiple Jobs.
The best way to grant access on specific projects to specific people is to use Role Strategy Plugin. It is just a piece of cake to configure this Plugin and it allows you to manage your Jenkins instance effectively.

So, here is a step-by-step guide to configure Role Strategy Plugin.

1. Login to Jenkins and click on Manage Jenkins

2. Click on “Configure Global Security”

3. Under “Authorization”, select “Role Based Strategy”. Save the changes.

4. Click on “Manage Jenkins” once again and then click “Manage and Assign Roles”

5. There will be three options displayed, Select the first one.

6. Click on Manage Roles and add a new Global Role. I call this role “Developer”

7. Provide Read access under “Overall” tab

8. Provide Build and Cancel access under “Job” tab.

9. Add Project Roles based on each project.

10. There are two configurable items in Project Roles
a. Role name – This is usually name of the project (e.g. myproject)
b. Pattern – It matches all the projects starting with same name. If you have multiple instances of same project then you can specify something like “myproject*”

11. Provide Build, Cancel and Read access under “Job” tab
For any reason, if we have to provide “Configure” permission later on, we can simple select “Configure” and it will get applied for all users.

12. Save the settings and click on “Assign Roles” from next screen.

13. Add users in Global Roles and grant access on “developer” role. It will be applicable for all developers.

14. Under “Project Roles”, add users and grant them access on specific projects, as applicable.
One user can be a part of multiple projects.

15. Save the settings.

16. Now when that user logs in, he/she will be able to see only those projects which have been granted access on.
As per our configuration, user “testuser (TEST)” is only able to see “myproject” project. He can only start and cancel the build process but cannot configure anything.


Create Puppet modules using Defined Types

Getting Started with Puppet Like Classes, Defined Type is also used to create Puppet modules. However, it is still different from Classes.

Defined Types are dynamic in nature. It means you can pass some arguments while calling Defined Types. The actual value will be replaced by the value passed in the argument.

Let’s try to understand with a real world example.  I need to add a new site in Apache, which means I need to create a new virtual host for that particular website. In order to make this process dynamic, I will have to create a new virtual host Config file every time a new site needs to be added. Rather than doing it manually all the time, I’ll be using Puppet to automate this process.

Here is the example which explains this process.

  1. Create a Defined Type, which accepts two run-time arguments:
    1. Name of the website/virtual host
    2. Content of the virtual host
  2. Call that Defined Type and pass the run-time values.

1. Define the “Defined Type”

 define virtual_host($content) { file { "/etc/apache2/sites-available/$name": ensure => 'file', owner => 'root', group => 'root', mode => '644', content =>$content; } }
2. Call the “Defined Type”
 virtual_host { 'example.net': content => file('/etc/puppet/modules/apache2/files/vhosts/example.net'); }
In the above example, the website/virtual host name is “example.net” and source for the content is a file which is place on the Puppet server itself (within the module).