JENKINS TIPS Ideas for making your life with Jenkins easier

JENKINS TIPS November 2014

“ When presented with a choice, pick a solution that’s easy to configure and maintain. ” (Me, just now)

DISCLAIMER: This presentation is not meant to be regarded as scripture. Instead, it captures the author’s personal preferences when dealing with Jenkins as a Continuous Integration server. Working software not releasable software - the code will be carried forward, re-factored and hardened for the first release.

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

Standalone installation vs. Deploying to an application server 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

Editing Jenkins’ configuration file 1.b) Post install configuration Editing Jenkins’ configuration file The jenkins.xml file is located in Jenkins' installation folder (Windows 32-bit 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)

Running Jenkins as “Local System” vs. Using a dedicated account 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))

Jenkins Global Settings 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.

Updating Jenkins and 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:

Updating Jenkins and plugins 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 shouldn’t happen very often) plugins: don’t fix it if it’s not broken - I wouldn’t 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)

Installing additional plugins 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

Configuring the email-ext plugin for a gmail account 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; don’t 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)

Out of the box, Jenkins keeps everything forever! 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)

Keeping build and automated tests projects separated 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

Can be executed before/during/after 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

Build triggering strategies: 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 Don’t spam! Only send notifications for failed builds (configure trigger in the extended email plugin’s “Advanced Settings”)

Q & A