JENKINS TIPS

Ideas for making your life with Jenkins easier

DISCIPLINED INNOVATION

JENKINS TIPS
November 2014

 When presented with a

choice, pick a solution
thats easy to configure
and maintain.
(Me, just now)

DISCLAIMER:
This presentation is not meant to be
regarded as scripture. Instead, it
captures the authors personal
preferences when dealing with
Jenkins as a Continuous Integration
server.

CONTENT TABLE
The presentation is divided into two big chapters:
1. Jenkins configuration
2. Jenkins project configuration

Internal Only

1. Jenkins configuration
1.a Jenkins installation
1.b Post install configuration

Internal Only

1.a) Jenkins installation

Standalone installation
vs.
Deploying to an application server
Standalone installation:
- Native package available for Windows, MacOS and most popular
Linux/BSD distros
- On Windows, Jenkins is installed as an independent service, and it is
configured to start automatically upon system boot

Deploying to an application server potential advantages:

- no extra port used :)
- slightly lower RAM usage, in theory

1.b) Post install configuration

Editing Jenkins configuration file

The jenkins.xml file is located in Jenkins' installation folder (Windows 32bit default: C:\Program Files (x86)\Jenkins\).
Recommended : change Jenkins' HTTP port from its default value of
8080 (to prevent current / future Tomcat conflicts)
Optional: change java version / java arguments (i.e -XX:UseGCOverheadLimit -Dmail.smtp.starttls.enable="true" -Xms256m
-Xmx512m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled)

1.b) Post install configuration

Running Jenkins as Local System

vs.
Using a dedicated account
The Windows Jenkins service runs as the Local System user by
default; change it to a dedicated account to get rid of PATH-related
headaches (i.e. missing folders/configuration files for Maven / Ant
builds; personal experience with grunt (JS build tool))

1.b) Post install configuration

Jenkins Global Settings

(http://localhost:<HTTP_port>/configure)
The Global Settings screen exposes a limited set of basic configs,
including:
- workspace / build root directories
- number of executors: number of concurrent build jobs
- JDK, ANT, Maven installations
This screen will also be used for configuring additional plugins.

1.b) Post install configuration

Updating Jenkins and plugins

Often, when accessing the Manage Jenkins section, you will be
greeted with the following screen:

1.b) Post install configuration

Updating Jenkins and plugins

Personal suggestions for updating Jenkins / plugins:
- Jenkins: go right ahead, you can always downgrade if needed
(which shouldnt happen very often)
- plugins: dont fix it if its not broken - I wouldnt recommend
updating plugins for no good reason, especially after you start
configuring projects using those plugins (as a practical
example, Jenkins comes with a 1.x version of the SVN plugin,
while early versions of the 2.x plugin did not support SVN
format 1.8)

1.b) Post install configuration

Installing additional plugins

(http://localhost:<HTTP_port>/pluginManager/available)
Useful plugins:
1) pre-scm-buildstep allows running tasks before code checkout
2) Deploy to container plugin deploy war to application server
3) Email-ext plugin provides an upgrade over the default email
plugin, being more configurable
4) GitHub Plugin adds Git support (Jenkins doesn't support Git
repositories out of the box)
5) Gradle Plugin adds Gradle support
6) Cucumber Reports Plugin adds support for creating "pretty"
Cucumber reports

1.b) Post install configuration

Configuring the email-ext plugin for a gmail account

2. Project configuration
2.a Staging environment
2.b Managing disk usage
2.c Downstream projects
2.d Using scripts
2.e Build triggers
2.f Email notifications

Internal Only

2.a) Staging environment

Test project updates in a staging environment

before applying them to your production Jenkins!
However, if the staging environment is on a
development machine, make sure you keep your
workspaces separated; dont check Advanced
Project Options - Use custom workspace (personal
experience with conflict between IntelliJ IDEA
which uses the locally installed SVN client and
Jenkins which uses its SVN plugin)

2.b) Managing disk usage

Out of the box, Jenkins keeps everything forever!

Check "Days to keep artifacts" / "Max # of builds to keep with artifacts" (as appropriate)
if you only want to delete artifacts (war,jar,zip) but keep logs/reports for project metrics!

N.B: Depending on project specifics, additional clean up may be required (e.g. C:\Windows\Temp)

2.c) Downstream projects

Keeping build and automated tests projects separated

Define independent projects for build / automated tests

Use "Build other project" post-build action on the main build, check "Block
build when downstream project is building" Advanced option

Only include a small set of smoke tests to run for each build; run full
automated regression for the "nightly" build

2.d) Using scripts

Highly recommended for control freaks (can be used to replace

some plugins, e.g. deploy, which fails sometimes)
Can be executed before/during/after build
For project independence, use embedded scripts if you don't
want to keep track of your files

2.e) Build triggers

Build triggering strategies:

Use Build periodically for nightly builds
Poll SCM for everything else
For impatient people, builds can be triggered on
commit
- copy .git\hooks\post-commit.sample to .git\hooks\post-commit
- add the following line to the post-commit file:
curl http://localhost:<port>/job/<yourJob>/build?delay=0sec

2.f) Email notifications

Dont spam!

Only send notifications for failed builds (configure trigger in the

extended email plugins Advanced Settings)

Q&A