Hi all,
It's been quite long time that, i haven't posted any blog.
This time, I'm going to describe how we can install and configure Jenkins for continuous integration for Java projects including plugins for test reports etc.
Jenkins Setup and configuration of plugins
Pre-requisites
- Java Development Kit (JDK) 1.7 and above
- Browser (Preferred: Firefox/Chrome)
- Maven (if required)
- Set the environment variables and path (JAVA_HOME, MAVEN_HOME, path)
Download
· Select the Java web archieve (.war) file to download
Installation
- Once the war file has downloaded, please run the war file from command prompt with the following command
- Cmd> java –jar Jenkins.war
- Note: Don’t close the command prompt where you had run the Jenkins war.
- Open the URL http://: in browser for configuration.
- By default hostname is localhost and port is 8080
- Default URL: http://localhost:8080
- Jenkins homepage shall be displayed
- By default, there will be no authentication (login) and security.
- First thing, you need to do is configure the system with the following items
- Click on “Manage Jenkins” and select “Configure System”
- [Optional] Update home directory
Configuration
Create new job
· To create a new job, click on the “New Item” from home page
· Select the project type based on your implementation and requirement
· After selecting any one from the type of the project specified above, we need to setup project
Job properties
Project name
Enter the project name
Description
Enter the project description with an overview
Discard build
This controls the disk consumption of Jenkins by managing how long you'd like to keep records of the builds (such as console output, build artifacts, and so on.) Jenkins offers two criteria:
Driven by age. You can have Jenkins delete a record if it reaches a certain age (for example, 7 days old.)
Driven by number. You can have Jenkins make sure that it only maintains up to N build records. If a new build is started, the oldest record will be simply removed.
Jenkins also allows you to mark an individual build as 'Keep this log forever', to exclude certain important builds from being discarded automatically. The last stable and last successful build are always kept as well.
Figure 1: Discard old builds
Run the build on specific node
Assigning labels to node
Manage Jenkins->Manage Node->Select node->Click Configure->Labels->enter the label(s)
Assigning node to build for execution
- Click on the build
- Select Configure
- Check “Restrict where this project can be run” option
- Enter the label which is been assigned to the node
Restrict where this project can be run
If you want to always run this project on a specific node/slave, just specify its name. This works well when you have a small number of nodes.
As the size of the cluster grows, it becomes useful not to tie projects to specific slaves, as it hurts resource utilization when slaves may come and go. For such situation, assign labels to slaves to classify their capabilities and characteristics, and specify a boolean expression over those labels to decide where to run.
Valid Operators
The following operators are supported, in the order of precedence.
· (expr)
o parenthesis
· !expr
o negation
· expr&&expr
o and
· expr||expr
o or
· a -> b
o "implies" operator. Equivalent to !a|b. For example, windows->x64 could be thought of as "if run on a Windows slave, that slave must be 64bit." It still allows Jenkins to run this build on linux.
· a <-> b
o "if and only if" operator. Equivalent to a&&b || !a&&!b. For example, windows<->sfbay could be thought of as "if run on a Windows slave, that slave must be in the SF bay area, but if not on Windows, it must not be in the bay area."
All operators are left-associative (i.e., a->b->c <-> (a->b)->c ) An expression can contain whitespace for better readability, and it'll be ignored.
Label names or slave names can be quoted if they contain unsafe characters. For example, "jenkins-solaris (Solaris)" || "Windows 2008"
Figure 2: Node specific project execution
Source Code management
Figure 3: Source code management
Please find the properties explanation below
Repository URL
Specify the subversion repository URL to check out, such as "http://svn.apache.org/repos/asf/ant/". You can also add "@NNN" at the end of the URL to check out a specific revision number, if that's desirable. This works for Subversion Revision Keywords and Dates like e.g. "HEAD", too.
When you enter URL, Jenkins automatically checks if Jenkins can connect to it. If access requires authentication, it will ask you the necessary credential. If you already have a working credential but would like to change it for other reasons, click this link and specify different credential.
During the build, revision number of the module that was checked out is available through the environment variable SVN_REVISION, provided that you are only checking out one module. If you have multiple modules checked out, use the svnversion command. If you have multiple modules checked out, you can use the svnversion command to get the revision information, or you can use the SVN_REVISION_ environment variables, where is a 1-based index matching the locations configured. The URLs are available through similar SVN_URL_ environment variables.
Credentials
Add your credentials which are required to authenticate the repository URL
Local Module Root
Specify a local directory (relative to the workspace root) where this module is checked out. If left empty, the last path component of the URL is used as the default, just like the svn CLI. A single period (.) may be used to check out the project directly into the workspace rather than into a subdirectory.
Repository depth
--depth option for checkout and update commands. Default value is infinity.
· Empty
Includes only the immediate target of the operation, not any of its file or directory children.
· Files
Includes the immediate target of the operation and any of its immediate file children.
· Immediates
Includes the immediate target of the operation and any of its immediate file or directory children. The directory children will themselves be empty.
· Infinity
Includes the immediate target, its file and directory children, its children's children, and so on to full recursion.
· as-it-is
Takes the working depth from the current working copy, allows for setting update depth manually using --set-depth option.
Check-out Strategy
Different types of svn checkout is possible while building the project.
Please find the available check out options below.
1. Use 'svn update' whenever possible
Use 'svn update' whenever possible, making the build faster. But this causes the artifacts from the previous build to remain when a new build starts.
2. Always check out a fresh copy
Delete everything first, then perform "svn checkout". While this takes time to execute, it ensures that the workspace is in the pristine state.
3. Emulate clean checkout by first deleting unversioned/ignored files, then 'svn update'
Jenkins will first remove all the unversioned/modified files/directories, as well as files/directories ignored by "svn:ignore", then execute "svn update". This emulates the fresh check out behaviour without the cost of full checkout.
4. Use 'svn update' as much as possible, with 'svn revert' before update
Do 'svn revert' before doing 'svn update'. This slows down builds a bit, but this prevents files from getting modified by builds.
Figure 4: Checkout types
Build Triggers
This section gives more options to automatically building the project
1. Build whenever a SNAPSHOT dependency is built
If checked, Jenkins will parse the POMs of this project, and see if any of its snapshot dependencies are built on this Jenkins as well. If so, Jenkins will set up build dependency relationship so that whenever the dependency job is built and a new SNAPSHOT jar is created, Jenkins will schedule a build of this project.
This is convenient for automatically performing continuous integration. Jenkins will check the snapshot dependencies from the element in the POM, as well as s and s used in POMs.
If this behavior is problematic, uncheck this option.
2. Trigger builds remotely (e.g., from scripts)
Enable this option if you would like to trigger new builds by accessing a special predefined URL (convenient for scripts).
One typical example for this feature would be to trigger new build from the source control system's hook script, when somebody has just committed a change into the repository, or from a script that parses your source control email notifications.
You'll need to provide an authorization token in the form of a string so that only those who know it would be able to remotely trigger this project's builds.
3. Build after other projects are built
Set up a trigger so that when some other projects finish building, a new build is scheduled for this project. This is convenient for running an extensive test after a build is complete, for example.
This configuration complements the "Build other projects" section in the "Post-build Actions" of an upstream project, but is preferable when you want to configure the downstream project.
4. Build periodically
Provides a cron-like feature to periodically execute this project.
This feature is primarily for using Jenkins as a cron replacement, and it is not ideal for continuously building software projects. When people first start continuous integration, they are often so used to the idea of regularly scheduled builds like nightly/weekly that they use this feature. However, the point of continuous integration is to start a build as soon as a change is made, to provide a quick feedback to the change. To do that you need to hook up SCM change notification to Jenkins.
So, before using this feature, stop and ask yourself if this is really what you want.
5. Poll SCM
This field follows the syntax of cron (with minor differences). Specifically, each line consists of 5 fields separated by TAB or whitespace:
MINUTE HOUR DOM MONTH DOW
MINUTE Minutes within the hour (0–59)
HOUR The hour of the day (0–23)
DOM The day of the month (1–31)
MONTH The month (1–12)
DOW The day of the week (0–7) where 0 and 7 are Sunday.
To specify multiple values for one field, the following operators are available. In the order of precedence,
* specifies all valid values
M-N specifies a range of values
M-N/X or */X steps by intervals of X through the specified range or whole valid range
A, B ... Z enumerates multiple values
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
The H symbol can be used with a range. For example, H H(0-7) * * * means sometime between 12:00 AM (midnight) to 7:59 AM. You can also use step intervals with H, with or without ranges.
The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project.
Beware that for the day of month field, short cycles such as */3 or H/3 will not work consistently near the end of most months, due to variable month lengths. For example, */3 will run on the 1st, 4th …31st days of a long month, then again the next day of the next month. Hashes are always chosen in the 1-28 range, so H/3 will produce a gap between runs of between 3 and 6 days at the end of a month. (Longer cycles will also have inconsistent lengths but the effect may be relatively less noticeable.)
Empty lines and lines that start with # will be ignored as comments.
In addition, @yearly, @annually, @monthly, @weekly, @daily, @midnight, and @hourly are supported as convenient aliases. These use the hash system for automatic balancing. For example, @hourly is the same as H * * * * and could mean at any time during the hour. @midnight actually means sometime between 12:00 AM and 2:59 AM.
Examples:
# Every fifteen minutes (perhaps at: 07, :22, :37, :52)
H/15 * * * *
# Every ten minutes in the first half of every hour (three times, perhaps at: 04, :14, :24) H(0-29)/10 * * * *
# Once every two hours every weekday (perhaps at 10:38 AM, 12:38 PM, 2:38 PM, 4:38 PM)
H 9-16/2 * * 1-5
# Once a day on the 1st and 15th of every month except December
H H 1, 15 1-11 *
Figure 5: Build triggers
Pre-Steps
Based on the project and available plugins, we can choose a pre-build setup if required.
Figure 6: Available pre-build steps
Build
Root POM
If your workspace has the top-level pom.xml in somewhere other than the 1st module's root directory, specify the path (relative to the module root) here, such as parent/pom.xml.
If left empty, defaults to pom.xml
Goals and options
Specifies the goals to execute, such as "clean install" or "deploy". This field can also accept any other command line options to Maven, such as "-e" or "-DskipTests=true".
Please find the maven project build example below
Figure 7: Build goals
Post Steps
Based on the project and plugin installed, the post steps will be displayed.
Figure 8: Available Post Steps
Build Settings
Based on the plugins installed, you will be finding the build settings and configure accordingly with health thresholds, health priorities, status thresholds.
Figure 9: Build settings advance options
Figure 10: Build settings
Post-Build Actions
Post build actions used to generate reports, archive artifacts etc.
Figure
11: Post build actions
Archive the artifacts
By selecting the archive the artifacts option, we can give the file which we can show it in the project dashboard for download purpose.
Figure 12: Archive the artifacts
Plugins and configuration
Jacoco Code coverage
1. Add the respective dependencies in your project pom.xml
2. Go to project configuration (Project->Configure)
3. Select “Add post-build action” then select “Record Jacoco coverage report”
Figure 13: Jacoco coverage report
Performance Report
1. Go to project configuration (Project->Configure)
2. Select “Add post-build action” then select “Publish performance report”
Figure 14: Performance report setup
Make sure that you are running all the test in your build by giving the goal
Figure
15: Project goal to run testcases
Blockers and resolution
FATAL error: Perm Jen Space (Out of Memory)
Update the jenkins.xml in the program files directory with the following java arguments
-XX:MaxPermSize=512m -Xmx2048M
Dependencies download error
When we faced an issue with dependency download error, we have the following options.
- Re-run the build by cross verifying the project pom.xml
- Manually download the jar from the maven repository and place in the respective .m2 directory
Jenkins taking long time to restart after install/update plugin
Wait for some decent time around 10-15 min to Jenkins restart and then try one of the following methods
- Restart Jenkins from services/command line depending on the type of installation.
- If the above methods doesn’t seems to work then as last choice, restart the Jenkins machine
Modules
Project Types
Freestyle project
This is the central feature of Jenkins. Jenkins will build your project, combining any SCM with any build system, and this can be even used for something other than software build.
Maven project
Build a maven project. Jenkins takes advantage of your POM files and drastically reduces the configuration.
External Job
This type of job allows you to record the execution of a process run outside Jenkins, even on a remote machine. This is designed so that you can use Jenkins as a dashboard of your existing automation system. See the documentation for more details.
Multi-configuration project
Suitable for projects that need a large number of different configurations, such as testing on multiple environments, platform-specific builds, etc.
Copy existing Item
