Jenkins – A Continuous Integration Tool

Introduction

Continuous Integration also known as CI is a software development practice where members of a team integrate their work frequently, leading to multiple integrations per day. The integration is verified by an automated build to detect integration errors as quickly as possible. This approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. It has the potential to enable and trigger a series of incremental process improvements, going from a simple scheduled automated build right through to continuous delivery into production. A good CI infrastructure can streamline the development process right through to deployment, help detect and fix bugs faster, provide a useful project dashboard for both developers and non-developers, and ultimately, help teams deliver more real business value to the end user.

Continuous Integration, in its simplest form, involves a tool that monitors the version control system for changes. Whenever a change is detected, it automatically compiles and tests the code. If it fails, then the tool immediately notifies the developers so that they can fix the issue. Continuous Integration can also help to keep tabs on the health of the code base, automatically monitoring code quality and code coverage metrics, and helping keep technical debt down and maintenance costs low.

Jenkins is an open source continuous integration tool written in Java. Jenkins was originally, known as Hudson. In 2009, Oracle purchased Sun and inherited the code base of Hudson. In early 2011, the project forked into two separate entities: Jenkins, run by most of the original Hudson developers, and Hudson, which remained under the control of Oracle. Jenkins is used by teams of all sizes, for projects in a wide variety of languages and technologies, including .NET, Ruby, Groovy, Grails, PHP and more, as well as Java. Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron (time-based job scheduler in Unix-like computer operating systems). Jenkins mainly focuses on two jobs:

1. Building/testing software projects continuously Jenkins provides an easy-to-use continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
2. Monitoring executions of externally-run jobs even those that are run on a remote machine. Jenkins keeps those outputs and makes it easy for you to notice when something is wrong.

Features

Jenkins offers the following features:

1. Easy installable using war or deployable on the servlet container
2. Jenkins can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help.
3. Jenkins can generate a list of changes made into the build from Subversion/CVS. This is also done in a fairly efficient fashion, to reduce the load on the repository.
4. Jenkins gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
5. Monitors build results by RSS or e-mail to get real-time notifications on failures.
6. Builds can be tagged long after builds are completed
7. JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc.
8. Jenkins can distribute build/test loads to multiple computers.
9. Jenkins can keep track of which build produced which jars, and which build is using which version of jars, and so on.
10. Jenkins can be extended via 3rd party plugins.

Installation

Jenkins is easy to install, and can run just about anywhere. The first step for starting the installation of Jenkins is to install Java on the machine where we intend to install Jenkins. Jenkins is a Java web application, so to run Jenkins, minimally you need to have Java Runtime Environment (JRE) 1.5 or later. If we need to check the availability of the java in the system, we need to give the following command in by opening DOS console on windows

C:\Users\admin\> java -version

The above command displays the latest running version of java in the system. If Java is installed on the machine, we should get the following message:

java version "1.7.0_17"

Java(TM) SE Runtime Environment (build 1.7.0_17-b02)

Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)

If we don’t have a version already installed, or if your version is an older one i.e., less than 1.5 then, download and install the latest JRE installer from the Java website.

For Windows users, there is a graphical Windows installation package for Jenkins. The installer comes in the form of a ZIP file containing an MSI package for Jenkins, as well as a setup.exe file that can be used to install the .NET libraries if they have not already been installed on the machine. In most cases, all we need to do is to unzip the zip file and run the jenkins-x.x.msi file inside. The MSI installer comes bundled with a bundled JRE, so no separate Java installation is required. Once we have run the installer, Jenkins will automatically start on port 8080. The installer will have created a new Jenkins service that can be started and stopped just like any other Windows service. There are also excellent native packages for Mac OS X and most of the major Linux distributions, including Ubuntu, RedHat (including CentOS and Fedora) and OpenSolaris.

If we are not installing Jenkins using one of the native packages, we can simply download the latest binary distribution from the Jenkins website. Once downloaded, we have to place it in an appropriate directory on the build server. On a Windows environment, we might put it in a directory called C:\Tools\Jenkins (It is a good practice to not to place Jenkins in a directory containing spaces in the path, such as C:\Program Files, as this can cause problems for Jenkins in some circumstances). On a Linux or UNIX box, it might go in /usr/local/jenkins, /opt/jenkins, or in some other directory, depending on the local conventions.

Preparing Build Server for Jenkins

Installing Jenkins on the local development machine is one thing, but installing Jenkins on a proper build server deserves a little more forethought and planning. Before we start the installation, the first thing we will need is a build server. To work well, Jenkins needs both processor power and memory. Jenkins itself is a relatively modest Java web application. However, in most configurations, at least some of the builds will be run on the principal build server. Builds tend to be both memory and processor-intensive operations, and Jenkins can be configured to run several builds in parallel. Depending on the number of build jobs we are managing, Jenkins will also need memory of its own for its own internal use. The amount of memory required will depend largely on the nature of the builds. A build server also needs CPU horsepower. As a convention, we will need one processor per parallel build. It is also in the best interest to dedicate your build server as much as possible to the task of running continuous builds.

In particular, we should avoid memory or CPU-intensive applications such as test servers, heavily-used enterprise applications, enterprise databases such as Oracle, enterprise mail servers, and so on.

The memory usage of a Continuous Integration server is best described as spiky—Jenkins will be creating additional JVMs as required for its build jobs, and these need memory. Another useful approach is to set up multiple build machines. Jenkins makes it quite easy to set up “slaves” on other machines that can be used to run additional build jobs. The slaves remain inactive until a new build job is requested—then the main Jenkins installation dispatches the build job to the slave and reports on the results. This is a great way to absorb sudden spikes of build activity.

Jenkins Home Directory

Jenkins keeps all its important data in a special separate directory called the Jenkins home directory. Here, Jenkins stores information about the build server configuration, build jobs, build artifacts, user accounts, and other useful information, as well as any plugins that may have installed. The Jenkins home directory format is backward compatible across versions, so we can freely update or reinstall your Jenkins executable without affecting the Jenkins home directory. By default, the Jenkins home directory will be called .jenkins, and will be placed in the home directory. For example, if we are running a machine under Windows 7, and username is “admin”, we would find the Jenkins home directory under C:\Users\admin\.jenkins. Under Windows XP, it would be C:\Documents and Settings\Admin\.jenkins. On a Linux machine, it would be under /home/admin/.jenkins. And so on. We can force Jenkins to use a different directory as its home directory by defining the JENKINS_HOME environment variable. If we are running Jenkins in a Java EE container such as Tomcat or JBoss, we can configure the webapp to expose its own environments variables. For example, if we are using Tomcat, you could create a file called jenkins.xml in the $CATALINA_BASE/conf/localhost directory:

<Context docBase="../jenkins.war">

<Environment name="JENKINS_HOME" type="java.lang.String"

value="/data/jenkins" override="true"/>

</Context>

Jenkins will look for its home directory in the following places (by order of precedence):

1. A JNDI environment entry called JENKINS_HOME

2. A JNDI environment entry called HUDSON_HOME

3. A system property named JENKINS_HOME

4. A system property named HUDSON_HOME

5. An environment variable named JENKINS_HOME

6. An environment variable named HUDSON_HOME

7. The .hudson directory in the user’s home directory, if it already exists

8. The .jenkins directory in the user’s home directory

Starting Up Jenkins

There are several ways to run Jenkins on the machine. One of the easiest ways to run Jenkins for the first time is to use Java Web Start (JNLP - Java Web Start is a technology that lets you start up a Java application on the local machine via a URL on a web page—it comes bundled with the Java JRE). In our case, this will start a Jenkins server running on the machine, and let us experiment with it as if it were installed locally. All we need for this to work is a recent (Java 1.5 or later) version of the Java Runtime Environment (JRE).

The link to the JNLP is available under Test drive section Meet Jenkins page. When we click on the Launch button the browser will ask if you want to open a file called jenkins.jnlp using Java WebStart. Click on OK—this will download Jenkins and start it up on the machine.

 

      

   

Java Web Start will only need to download a particular version of Jenkins once. From then on, when we click on the “Launch” button again, Java Web Start will use the copy of Jenkins it has already downloaded. Ignore any messages your operating system or anti-virus software may bring up—it is perfectly safe to run Jenkins on the local machine. Once it has finished downloading, it will start up Jenkins on your machine. We will be able to see it running in a small window called “Jenkins Console”

To stop Jenkins at any time, just close this window.

There are also installers available for the principal operating systems such as Windows, Ubuntu/Debian, Red Hat/Fedora/CentOS, Mac OS X, openSUSE, FreeBSD, OpenBSD, Solaris/OpenIndiana, Gentoo available on the Jenkins website.

Or, we may prefer to simply download the latest version of Jenkins war file (jenkins.war) and run it from the command line. Jenkins comes in the form of an executable WAR file. Once downloaded, we can start Jenkins from the command line as shown here:

C:\Users\admin\>java -jar jenkins.war

Whether we have started Jenkins using Java Web Start or from the command line, Jenkins should now be running on the local machine. By default, Jenkins will be running on port 8080, so we can access Jenkins in the web browser on url http://localhost:8080/. Alternatively, we can simply deploy the Jenkins WAR file to the application server such as Glassfish, IBM WebSphere, JBoss, Jenkins deployment in Apache Geronimo 3.0, Jetty, Jonas, Tomcat, Weblogic and Winstone.

If we are running Jenkins on an application server, the URL that we use to access Jenkins will be slightly different. On a default Tomcat installation, for example, we can access Jenkins in your web browser on http://localhost:8080/jenkins. When we open Jenkins in the browser, we should see a screen like the one shown below image

Configuring Jenkins

Before we get started, we need to do configure Jenkins. That is, we need to tell Jenkins about the build tools and JDK versions which will be used for the builds. Click the “Manage Jenkins” link on the home page. This will take us to the Manage Jenkins page, the central one-stop-shop for the entire Jenkins configuration. From this screen, we can configure our Jenkins server, install and upgrade plugins, keep track of system load, manage distributed build servers, and more

Clicking on the “Configure System” link will take us to the Configuration page. From here we can configure everything from security configuration and build tools to email servers, version control systems and integration with third-party software. The screen contains a lot of information, but most of the fields contain sensible default values, so we can safely ignore them.

Configuring JDK

If we have a Java JDK (as opposed to a Java Runtime Environment—the JDK contains extra development tools such as the Java compiler) already installed on the workstation, we can simply provide the path to the JDK in the JAVA_HOME field. Otherwise, we can ask Jenkins to download the JDK from the Oracle website the first time a build job requires it. We need to just pick the JDK version we need and Jenkins will take care of all the logistics. However, for licensing reasons, we will also need to tick a checkbox to indicate that we agree with the Java SDK License Agreement.

Notification

Another important aspect we would typically set up is notification. When a Jenkins build breaks, and when it works again, it can send out email messages to the team to spread the word. Using plugins, we can also get it to send instant messages or SMS messages, post entries on Twitter, or get people notified in a few other ways. It all depends on what works best for our organizational culture. Email notification is easy enough to set up if we know your local SMTP server address. We need to just provide this value in the Email Notification section towards the bottom of the main configuration page.

Plugins

Jenkins supports many 3rd party plugins to be able to use with the Jenkins application. The installation of new plugins and up gradation of the existing plugins is pretty simple. First of all, click on the “Manage Jenkins” link to the left of the screen to go back to the main configuration screen. Then click on Manage Plugins. This will open the plugin configuration screen, which is where we manage the extra features you want to install on your Jenkins server. There are four tabs namely Updates, Available, Installed, and Advanced. Click on the Available tab to see a very long list of available plugins. Find the plugin which suits our need and tick the corresponding checkbox, and then scroll down to the bottom of the screen and click on Install. This will download and install the plugin into the local Jenkins instance. Once it is done, we will need to restart Jenkins for the changes to take effect. To do this, you can simply click on the “Restart Jenkins when no jobs are running” button displayed on the installation screen, or alternatively we can shut down and restart Jenkins by hand.

Installing Subversion on Apache server in Windows 7

Installing Apache Server

Download and Install the latest version of Apache server from http://httpd.apache.org/download.cgi. Choose the installer that includes OpenSSL (httpd-2.2.22-win32-x86-openssl-0.9.x.msi). Once downloaded, Run the installer with the admin privileges and chose the default options. It is recommended to install for all users on Port 80.

Now test if the Apache web server is running correctly by pointing your web browser to http://localhost/ - a pre-configured Website should show up.

Installing the Subversion
Download the latest Subversion Win32 binaries for Apache at http://subversion.apache.org/packages.html#windows. Run the subversion installer and follow the instructions. Allow the default options to be checked for installation. After the installation check if the bin path of the Subversion is added to the ‘Path’ system variable. If not, add them manually. After adding the path, go to the command prompt and check if the installation is success by typing ‘svn’ and press enter. The below message should be displayed if the installation is successful.

After checking the installation, copy the files ‘mod_dav_svn.so’ and ‘mod_authz_svn.so’ from Subversion’s bin directory (Usually C:\Program Files (x86)\Subversion\bin) to Apache’s module directory (Usually C:\Program Files (x86)\Apache Software Foundation\Apache2.2\modules).
Then Copy the file libdb*.dll and intl3_svn.dll from the Subversion bin directory to the Apache bin directory.

Edit the Apache's configuration file (usually C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\httpd.conf) with a text editor such as Notepad/Editplus and make the following changes:
We will admin privileges to make changes to this file. Right click on Notepad and select ‘Run as administrator’ and then open the httpd.conf file.

Uncomment the following lines:

#LoadModule dav_fs_module modules/mod_dav_fs.so
#LoadModule dav_module modules/mod_dav.so

Add the following two lines to the end of the LoadModule section.

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so

Create a repository using svnadmin

Use the svnadmin command to create the svn repository.
 

Configuration
After setting up the Apache and Subversion, we need to configure the Apache to make the Apache understand which URL will be used for repositories. To do this we need to edit the Apache configuration file (we will require administrator privileges).
The configuration file is usually located in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\httpd.conf.

At the end of the config file add the following lines:

<Location /svn>
  DAV svn
  SVNListParentPath on
  SVNParentPath D:\Repositories
  AuthType Basic
  AuthName "Subversion repositories"
  AuthUserFile passwd
  #AuthzSVNAccessFile svnaccessfile
  Require valid-user
</Location>

The above changes configure the Apache server so that all the Subversion repositories are physically located below D:\Repositories. The repositories are served to the outside world from the URL http://MyIp/svn/ Access is restricted to known users/passwords listed in the passwd file. To create the passwd file, open the command prompt and change to the Apache server folder (C:\Program Files (x86)\Apache Software Foundation\Apache2.2) and create the passwd file using the below command.
C:\Program Files (x86)\Apache Software Foundation\Apache2.2>bin\htpasswd -c passwd <your user name>
It will prompt for the user to enter the password and on entering the password, press enter and then retype the password and then again press enter. Now the user credential will be created. And  this can be used to access the svn.

After creating the user, restart the Apache server.

Try accessing the url http://localhost/svn/  from the browser, the browser will prompt for the user name and password, enter the user name and password you created

If the login is success then use the repository is displayed below

Use any of the svn clients like TortoiseSVN to access the repository and checkout in to a folder.

PS:

• If the port 80 is already being used by some other application, you may get an error. So make sure that no application is using the port 80. To be more on the safer side, modify the ‘Listen 80’ line in the httpd.conf file to Listen 81 and restart the server. Now the link can be accessed from http://localhost:81/svn/
• The system may be behind the proxy, so check if entry http-proxy-host and http-proxy-port in the file C:\Users\<User>\AppData<hidden folder>\Roaming\Subversion\servers is uncommented and the appropriate IP is configured.

Sticky Footer on Popup using javascript

There are many articles on the Internet about the sticky footer which can be implemented in a Html page. But i did not find any information about the sticky footer which can be implemented on a pop up window.

Here is how to that can be done.

create a javascript function that can be called on a event like onclick, onload etc.

function launchPopup(){
var width = 500; //Width of popup
var height = 400; //Height of popup

/* popup positioning based on height and width*/
var left = parseInt((screen.availWidth/2) - (width/2));
var top = parseInt((screen.availHeight/2) - (height/2));

var windowFeatures = "width=" + width + ",height=" + height + ",status=no,toolbar=no,resizable=no,scrollbars=yes,left=" + left + ",top=" + top + "screenX=" + left + ",screenY=" + top;

var actionURL = "Popup.jsp"; // Create a jsp or html file with the name
popWindow =window.open(actionURL,"", windowFeatures);
popWindow.document.write("<html>");
popWindow.document.write("<style type ='text/css'>");
popWindow.document.write(".containers { height : 340px;}");
popWindow.document.write("</style>");

popWindow.document.write("<body>");
popWindow.document.write("<div class = 'containers'>");
popWindow.document.write("// content for popup");
popWindow.document.write("</div>");
popWindow.document.write("<div align='center'>");
popWindow.document.write("//Footer Content Goes here");
popWindow.document.write("</div>");
popWindow.document.write("</body>");
popWindow.document.write("</html>");
popWindow.document.title="My Popup";

}


Cannot find bean: xxx in scope: xxx

Hi,


Few days back, i came across this error 'Cannot find bean: "myList" in scope: "session" ' while using a struts application. After hours of digging the code, i finally found the cause of the error. It was due to the value "myList" being set null in session.

According to HttpSession API,

If the value passed in is null, this has the same effect as calling removeAttribute()

To avoid the value null being set to the sessionAttributes, use the following snippet.

myList = myLogic.getList();
if(myList==null)
{
session.setAttribute("myList",new ArrayList());
}
else
{
session.setAttribute("myList",myList);
}

Installation instructions for SOA 11g on Windows

SOA 11G Installation Procedures

The following are the list of files that are needed for installing SOA 11G

• server103_win32.exe (WebLogic 10.3.1)

• OracleXEUniv.exe (Oracle XE 10.2.0.1)

• rcuHome.zip (For Creating Database schema )

• ofm_soa_generic_11.1.1.1.0_disk1_1of1.zip

• jdevstudio11111install.jar

The browsers supported are Firefox 3 or IE 7.
The Java JDK 1.6 update 11 must be used for using SOA 11G
The database can be any of the following versions 10.2.0.1 or 10g database version 10.2.0.4+ or 11g database version 11.1.0.7+. Other versions are not supported.
If there is a database that is already installed in the pc, uninstall it and the install the new database.
Make sure processes parameter in the database is >=200.

sqlplus sys/welcome1@XE as sysdba
SQL> show parameter session
SQL> show parameter processes
SQL> alter system reset sessions scope=spfile sid='*';
SQL> alter system set processes=200 scope=spfile;
SQL> shutdown immediate
SQL> startup
SQL> show parameter session
SQL> show parameter processes

Installing Weblogic Server 10.3.1

a) Click on the weblogic installation file and give the path where the software needs to be installed.

b) Click Next
c) Enter email to register for security alerts or deselect the checkbox and decline – whichever you prefer, click Next
d) Select Typical, click Next
e) Review installation directories

f) Click Next
g) Select “All Users” Start Menu folder, click Next
h) Review Summary

i) Click Next to start the installation process. Install takes about 3 minutes.
j) When the install is complete, deselect Quickstart checkbox and click Done.

Creating Schema for SOA

The Repository Creation Utility(RCU) can be started by opening
RCU_HOME/bin/rcu.bat command

1. Click Next

2. Select Drop
3. Click Next
4. Complete the database information

5. Click Next
6. The pre-requisites are reviewed and when completed, click OK. The utility moves to the next page – with a slight delay, just wait for it.
7. The utility finds the existing schema and offers the list. Check that the prefix is correct and review the schema.

8. Click Next.
9. The pre-requisites are reviewed and when completed, click OK.  The utility moves to the next page – with a slight delay, just wait for it.

10. The utility finds the existing schema and offers the list.  Check that the prefix is correct and review the schema.11. On the drop schema warning, click OK.
12. The pre-requisites for this step are reviewed. When completed, click OK to move to the next page – with a slight delay, just wait for it.
13. Click Drop to drop the schema. This takes about 5 minutes.
14. When it is finished, Click Done.

Configure Schema
15. Now create the new schema. Run the bat file to open the RCU.
The bat command returns to the prompt immediately and in a minute or so, the Repository Creation Utility opens.
16. On the welcome screen, click Next
17. Select Create and click Next

18. Enter the database information 

19. Click Next
20. The pre-requisites are reviewed. When complete, click OK. The utility moves to the next page – with a slight delay, just wait for it.

21. On the Select Components screen, enter SH in the field for creating a new prefix. Select the SOA Infrastruture component. Dependent schemas are selected automatically.

22. Click Next
23. The pre-requisites for this step are checked. When completed, click OK.
24. Select the radio button to Use the same password for all schemas. Enter the schema password, welcome1. If you choose instead to use a secure password or a different one for each schema, be sure to record your passwords as you will need them later.

25. Click Next
26. Review the tablespaces and schema owners for the components

27. Accepting the defaults, click Next and then click OK to create the tablespaces.
28. When the pre-requisites for this step are completed, click OK

29. Click Create to create the tablespaces. This takes about 2 minutes
30. When completed, click Close.
Install SOA
30. In a command window enter
 cd c:\stage\soa\Disk1

setup -jreLoc C:\Oracle\Middleware\home_LOAD16F\jdk160_11

When the install wizard welcome screen comes up, click Next
a) Wait for the pre-requisite check to complete
b) Click Next
c) On the Specify Installation Location screen, select the Middleware home: C:\Oracle\Middleware\
d) Enter Oracle home: Oracle_SOA1
If you use a different Oracle home then adjust accordingly when Oracle_SOA1 is referenced throughout this document.

e) Click Next
f) Review summary

g) Click Install
h) Wait for the install to complete – takes a few minutes
i) Click Finish
Create Domain
31. In a command window enter
cd C:\Oracle\Middleware\..\Oracle_SOA1\common\bin

config.cmd
a) When the install wizard welcome screen comes up, select Create a new WebLogic domain, select Next
b) Select Generate a domain and select SOA, EM, and BAM. Dependent products are selected automatically

c) Click Next
d) Enter the domain name: domain1

e) Click Next
f) Enter user name weblogic and password welcome1, confirm password. If you choose instead to use a secure password for the admin, adjust accordingly later in the document when the password is referenced.

g) Click Next
h) Select the Sun SDK 1.6_11 and leave Development Mode checked

i) Click Next
j) On the Configure JDBC Component Schema screen, with all of the components selected, enter welcome1 for the password in the Schema Password field.
k) With all of the checkboxes selected, enter the Service and Host names.

l) Review the Schema Owner field and confirm that they are the same as what you configured in the Configure Schema section when you ran the RCU. You can review the screen shots in that section of this document for the schema owners.
m) Complete the following if the schema owners need to be updated:

1. Deselect all the component checkboxes and select BAM Schema.
2. Enter the Schema Owner, SH_ORABAM
3. Next, deselect BAM Schema and select the next one.
4. Enter the schema owners one-by-one by pre-pending SH_ to the defaulted value. SH is the prefix specified in the RCU.
5. Continue until all schema owners are entered (see screen shot).

n) Click Next.
o) The data source connections are all tested.

p) If all are successful, click Next, otherwise click Previous and correct any errors.
q) Click Next once more, accepting defaults (no optional configurations), and you reach the Configuration Summary screen.

r) Click Create.
s) Wait for the create to finish – takes just a minute

t) Click Done.