How to chain jobs in Jenkins using Parameterized trigger plugin

In Jenkins, sometimes we may need to trigger multiple jobs in a particular sequence, each performing some unique task. For instance let us consider a scenario, where we have one parent job to perform a maven build of a Java based project. We also have 2 separate child jobs for packaging - let's say one creates a Windows installer and the 2nd one which creates a Linux installer. Now, we want to automatically trigger the packaging jobs immediately after the build is finished. The Parameterized Trigger plugin helps us exactly to achieve the same. Using this, we can chain multiple jobs and pass parameters across them.

Let us consider the above scenario in some more detail.

Firstly, make sure the Parameterized Trigger plugin is installed in Jenkins.

Now, as said above I have one parent job which essentially performs a maven build of a Java based project. Once the build is finished, I want to trigger 2 child jobs - one which creates a Windows package and the other which creates a Linux package. In our case, we have the version 2.31 installed. Latest versions are available periodically.

Now, lets configure the chaining of packaging child job within the parent job i.e Maven build job. While doing so, I want to a bunch of pre-defined parameters across the build. For eg: I want to pass the build version and the location of Clearcase build view. The parameters could be either a constant variable or an environment variable.

Make sure to tick the option "This build is parameterized" and add a few parameters as desired.

Now add a new build step "Trigger/call builds on other projects" from the list.

Now all you have to do is mention the child build that you want to fire and the list of specific pre-defined parameters that you want to pass to it. Check the screenshot below for illustration.

Here we are passing 2 parameters - version and path_loc. Kindly note the syntax. Note that these 2 parameters need to be defined in both the parent and child jobs. In case you do not want to pass all the current build parameters instead of specific ones, simple choose the "Current build parameters" from the "Add Parameter dropdown list."

Alternatively, you could also pass the parameters from a specific properties file as well by specifying its location.

Ciao guys. Drop in your comments for any suggestions, questions or queries please. Grazie!

How to open specific port in firewall in CentOS Linux

Guys, if your organization is behind a firewall, the networking team usually takes care that most unused ports are blocked, unless absolutely necessary. In some cases, you may want to add an exception to the firewall rules though, to open up a specific port to allow incoming and outgoing network traffic.

In today's example, we may want to open up a port 8080 to allow TCP connections for instance. Note that these commands are specifically for the CentOS flavor of Linux. Other flavors of Linux may have different command syntax. Please check accordingly.

Firstly view the existing firewall rules using the following command

firewall-cmd --list-all

Output (Old rules):

public (default, active)
  interfaces: en0
  sources:
  services: dhcpv6-client ssh
  ports: 9005/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

As you see from the existing rules, it seems that port 9005 is open. Now let us add the port 8080 to the firewall rules using the below command. If the command is executed fine, it will display "success". Make sure to reload firewall configuration to bring the new rules into effect.

firewall-cmd --zone=public --add-port=8080/tcp --permanent
success

firewall-cmd --reload
success

In order to view the double check the firewall rules, again use the --list-all command.

firewall-cmd --list-all

Output ( Updated rules):

public (default, active)
  interfaces: en0
  sources:
  services: dhcpv6-client ssh
  ports: 8080/tcp 9005/tcp
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:

As you see the port 8080 has been added to the list i.e it has been opened up.

How to automate Jenkins config backup

In today's post on Jenkins, let us learn how to take regular backups of our Jenkins environment configuration. There are a bunch of plugins out there which can help take thin and/or thick backups. But in our post we learn to take backups using a custom batch script.

We write a simple batch file which recursively takes backup of all Jenkins jobs and saves them in the destination directory. Later we set up a Windows scheduler job to execute this batch file daily.

rem IroncladZone
echo OFF

set today=%DATE:~7,2%%DATE:~4,2%%DATE:~10,4%
set url=http://17.16.18.14:8080/jenkins/
set dest_dir=C:\Jenkins_Jobs_backup\

cd /d "C:\Program Files (x86)\Jenkins\jobs"

FOR /D %%i IN (*) DO (

echo "Backing up %%i.xml"

"C:\Program Files\Java\jdk1.8.0_45\bin\java" -jar jenkins-cli.jar -s %url% get-job "%%i" > "%dest_dir%/%%i_%today%.xml"

echo "Successfully backup %%i.xml"

)

Note for taking backups, we use Jenkins' command line utility i.e jenkins-cli.jar. With this we save the Jenkins job configuration .xml file at the destination folder. Note that we append this .xml file name with today's date time-stamp so that we could easily identify it later.

Now all we have to do is set a Windows task scheduler job which runs this batch file to take backups at say 12:00 noon daily.

Hope it helps folks. Ciao!

LDAP authentication for SonarQube 5.6

Guys, if your project uses SonarQube for analyzing and improving the code quality, this is the post you should be interested in. In this post, we look into how to configure the organization-specific LDAP settings for SonarQube version 5.6

First of all, before we proceed, in order to enable LDAP authentication in SonarQube, you will have to install the LDAP plugin from the update center. In this illustration, we have the LDAP plugin version 1.4 installed. Newer versions of the plugin will be available periodically.

Now, navigate through your SonarQube installation directory => conf folder to find the sonar.properties file.

In this file, you'll able to configure LDAP details to enable LDAP user authentication. In case you're not aware of the specific credentials, kindly check the same from an authorized  administrator.

A sample illustration below will give you the look and feel of how the LDAP settings should look like.

#-------------------------------------------------------------------------------------------------
# LDAP related settings
sonar.security.realm=LDAP
sonar.security.updateUserAttributes=false
ldap.url=ldap://17.16.10.14:389
ldap.bindDn=CN=BUILDER,OU=USERS,OU=AdminPRivilege,DC=company,DC=com
ldap.bindPassword=ldap-password-here
ldap.user.baseDn=dc=company,dc=com
ldap.user.request=(&(sAMAccountName={login}))

Note that the above values are just an example and will vary for each organization. For more information, kindly check the LDAP plugin page here.

How to generate report to list unused dependencies in Maven

In this post, we will see how to generate a report to list the unused dependencies of a Java project built using Maven.

We will use the dependency plugin to do so. Let's use the dependency:analyze-report goal as below

mvn dependency:analyze-report -DignoreNonCompile=true

This will basically generate an HTML report containing the list of dependencies with the following classification :

• used and declared.
• used and undeclared.
• unused and declared.

Ideally, it's always a good idea to cleanup the pom's by removing and/or commenting the unused but declared dependencies.

How to deploy specific file to Artifactory using Maven from Jenkins

This post will be helpful in a scenario where you are required to deploy i.e upload just a specific individual file (eg: xyz.zip or abc.jar) to Artifactory using Maven from Jenkins.

For illustration, configure a deploy-file job in Jenkins and add the following Maven goal.

clean deploy:deploy-file
-DgroupId=com.company.abc.message -DartifactId=message -Dversion=${version}
-DgeneratePom=false
-Dpackaging=jar
-DrepositoryId=artifactory
-Durl=http://17.16.18.12:8080/artifactory/simple/libs-release-local/
-Dusername=admin -Dpassword=admin-password
-Dfile=C:\Users\ironcladzone\Desktop\messageTest\message-${version}.jar

This will basically upload the message jar with a dynamically passed version parameter. Assuming the ${version} parameter value is defined 5.3.2 in Jenkins, the above command will essentially deploy message-5.3.2.jar to the libs-release-local repository.

Ciao!

Version increment and/or update using Maven

In today's fresh post, we will look into how to increment and/or update version numbers in pom.xml of your project using Maven.

Let's assume your project has a multi-module/multi-component setup. Each of the module/component has its own pom.xml with a list of dependencies and the overall bill of materials in general.

As a good practice, it's always a good idea to have about 2 pom's on the topmost levels. 1st pom should have all the project dependencies, which will be the parent pom of all modules. The 2nd pom should contain all third party non-project dependencies. This 2nd toplevel pom should be the parent of the 1st toplevel pom. These 2 toplevel pom's collectively define the project and 3rd party dependencies. Note that the versions of all dependencies should be defined in these 2 pom's. The individual module pom's should not carry the version number of dependencies. It will fetch them from the above 2 toplevel pom's.

Also, the module's own version should not be explicitly defined within it's own pom. It should only carry the version of it's parent pom. The below diagram should you help you visualize the ideal structure.

Let's say for instance the current version in current sprint is 5.3.3-7 and you want to update the version to 5.3.4-1 for going on to the next sprint. The following command can get that job done.

• mvn versions:set -DnewVersion=5.3.4-1

Refer the following maven versions plugin page for information.

Note however, that if your source code is under version control (for eg: IBM Clearcase), you may want to check out the files first, then update the versions in pom.xml and then check them in. In such a scenario, use the following sequence of commands to do so :

• cleartool find . -name pom.xml -exec "cleartool co -nc %CLEARCASE_PN%"

This will recursively checkout all pom.xml files within your Clearcase view.

• mvn versions:set -DnewVersion=5.3.4-1

This will increment all pom versions to 5.3.4-1

• cleartool find . -name pom.xml -exec "cleartool ci -nc %CLEARCASE_PN%"

Once the versions are updated, all you have to do is recursively checkin all the pom.xml's. The above command will do that. 

Please note that the above cleartool commands will only work if you're using IBM Clearcase for source control.

For any questions, queries or discussion's kindly drop a comment or two. Peace. Cheers!