External Use

TM

Continuous Integration with Hudson™ and Jenkins™

J U L . 0 2 . 2 0 1 4

Vlad Lică | Software Eng.

TM

External Use 2

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

TM

External Use 3

Hudson vs. JenkinsTimeline

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

TM

External Use 4

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)

TM

External Use 5

Plug-in selection

… there’s probably a plug-in that solves our problem

TM

External Use 6

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.

TM

External Use 7

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

TM

External Use 8

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})

TM

External Use 9

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

TM

External Use 10

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:\cygwin\bin\sh, #!c:\MinGW\msys\1.0\bin\bash –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

TM

External Use 11

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

TM

External Use 12

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

TM

External Use 13

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

Custom HTML

Groovy template extracting and formatting test results and coverage information

TM

External Use 14

Thank you

Q/A + Gerrit Demo

TM

© 2014 Freescale Semiconductor, Inc. | External Use

www.Freescale.com