1. External Use
TM
Continuous Integration with
Hudson™ and Jenkins™
J U L . 0 2 . 2 0 1 4
Vlad Lică | Software Eng.

2. TM
External Use 1
Introduction
• Hudson and Jenkins are an extendable set of Tools designed to quickly
set-up a Continuous Integration Infrastructure for a software development
project
• Written in Java™, the Hudson/Jenkins tools are widely used to support an
incremental development process, aiding developers across the board by
automatically running a set of “Jobs” to build, test and validate each
commit to the main source code repository. A way to avoid the so-called
“integration hell”.
• Running in a servlet container, the Hudson/Jenkins CI server provides a
http-accessible dashboard that allows us to inspect and configure various
Jobs that run in a cluster-like environment - a collection of physical hosts
and Virtual Machines which function as workers assigned to a main node
• Provides a wide range of plug-ins, integrating commonly-used
development tools, that address each step in the build-to-release pipeline:
source repository polling, easily scripting the build process, running tests,
generating performance reports, publishing a build for release and setting
up alerts and notifications

3. TM
External Use 2
Hudson vs. Jenkins
Timeline
2004 2011
• The “Butler” Wars
• Similar front-end dashboard
• Back-end API / Implementation differences
• Inter-compatibility/ports for most Plug-ins -> similar eco-system
• Maintainers: Eclipse Foundation (Hudson) vs. original Hudson developers
(Jenkins)
• In recent years, more commits/development activity favoring Jenkins
Hudson - Sun™ Hudson - Oracle™ Hudson – Eclipse Foundation™
Jenkins

4. TM
External Use 3
Setup
• The Hudson/Jenkins Dashboard
• Download and install the Jenkins server Application; Configuration is done through the
Jenkins Dashboard accessible at :8080
• Register main node (start-up script provided in Jenkins distribution)
• Register each physical or VM worker (for each slave machine, simply start provided script at
start-up, running jenkins-slave.jar to connect to master server)
• Install and configure commonly used build tools and environment variables in the main node;
the main node dispatches this configuration and tools to heterogeneous workers
• A one-time general configuration for machines running both Windows™ and Linux™
distributions; additional, specific tweaks can be made for each worker or in the context of a
specific job)

5. TM
External Use 4
Plug-in selection
… there’s probably a plug-in that solves our problem

6. TM
External Use 5
Job Types - Overview
• Regular CI jobs: regular polls made to a version control repository (Git) for any source changes; if changes are
detected, a full build of the entire code base (Java/Eclipse & C/C++) is triggered; runs a set of minimal unit tests and
static analysis; sends customized e-mail to either the commiter or a distribution list, reporting Success or Failure +
build log -> designed for fast turn-around: build time ~ 10-20 minutes
• Gerrit code review tool Integration (DEMO)
• Validation Jobs: run nightly, on schedule; perform a full build and run all possible tests (unit & run-time tests),
validation and performance measuring tools (static analysis, code coverage, memcheck, valgrind etc.). Reports are
sent by email and also integrated in the Jenkins Dashboard for stats trend inspection
• Weekly Release Jobs: manually triggered, the Release jobs are designed to publish an official build of the component
to the Internal File Server, along with logs, build reports and release notes: a history of changes on a release-by-
release basis is generated; runs the same steps as a Nightly Validation, but building a Release version; generates an
unique build number for version control and publishes all artifacts to the internal repository.

7. TM
External Use 6
Configuring a Jenkins Job – Common Flow
• Parameterized builds – allows to start a job with specific parameters; useful if
triggered from an upstream job or to address a specific build configuration
• Pre-build – source control
- Jenkins plug-ins for commonly used version control tools
- A build may be triggered by detecting changes made to the provided repository

8. TM
External Use 7
Configuring a Jenkins Job – Common Flow
• Version Control for Release build Jobs
− Jenkins plug-in to generate an unique build number for version
control, possibly combining time-stamp with the current build number
− The build number generated persists as a global environment
variable, visible in any build step of the current job (e.g.:
${BUILD_ID})

9. TM
External Use 8
Configuring a Jenkins Job – Build Steps
• Scripting a build in Jenkins is done in a modular fashion
• Combine build tool plug-ins and shell scripting in any number of sequential build steps, although too many are not recommended;
• A minor nitpick is that the Jenkins dashboard does not provide a pick-and-set configuration for build steps; if not well thought-out initially, they
can be cumbersome to reorder

10. TM
External Use 9
Configuring a Jenkins Job – Build Steps
• A very useful feature is the ability to open a shell at any point in the build flow
• No matter the OS host, if the build slave is properly configured, any type of shell may be opened by providing the
proper shebang as the first line (e.g. #!/bin/sh, #!c:cygwinbinsh, #!c:MinGWmsys1.0binbash –login etc.)
• The shell’s output is captured in real-time and may be viewed during the job from the Dashboard
• Jenkins also provides a set of useful environment variables that can be used in any build step

11. TM
External Use 10
Configuring a Jenkins Job – Tests & Validation
• Unit Tests
- Java/Eclipse: plug-ins are built using Tycho™; as such, the tycho-sure-fire plug-in is
configured in the project’s main pom.xml file to run unit/SWTBot tests
- C/C++: Unit tests are written using Google™ Test Framework and are run with CTest
tool
* Jenkins provides a plug-in to aggregate all test result reports .xml files and generate a
report/graph trend. Eclipse surefire defaults to the xunit format; for C/C++, a python
shell script converts the output reports to xunit

12. TM
External Use 11
Configuring a Jenkins Job – Tests & Validation
• Static Analysis
− Eclipse: Findbugs integration
• Code coverage tools
− C/C++:
 gcov tool + Cobertura Jenkins plug-in for publishing;
 python tool (gcovr) to wrap gcov-generated coverage reports to Jenkins Cobertura plug-in format
 Valgrind integration for run-time memory leak detection
− Eclipse: static/dynamic (run-time) tools
 Emma vs. Cobertura vs. Jacoco
 JaCoCo selected as coverage tool: excellent Jenkins integration; easy to set-up; supports plug-in
profiling; benefits from regular maintenance and releases; free

13. TM
External Use 12
Post Build – Email Notification
• Jenkins plug-in for Email Notifications
− Very flexible; provides a standard template, along with useful variables that expand to statistics, such as: build result status,
git commit, source changes, log file output, test results parsing and a lot more
− Manually code a custom html email OR use groovy/jelly script files to interface directly with Jenkins’ REST API and
extract/format any details regarding the build
− Custom triggers for Successful/Failed/Unstable builds

14. TM
External Use 13
Thank you

15. TM
© 2014 Freescale Semiconductor, Inc. | External Use
www.Freescale.com