Configuring a professional open source development environment – Part 2 By Thomas Arnbjerg, TechPeople, 2018 Jenkins Continuous Integration Server Introduction 2 Prerequisites 3 Installing Jenkins 3 Introduction 4 Steps 4 Installing external programs 7 Cppcheck 8 cpplint 9 sloccount 9 valgrind 10 gcovr 10 Eclipse 10 Installing Jenkins plugins 11 Creating a build job 12 Build job ‘HelloWorld’ 13 Generating a data basis 13 Visualizing the result 22 Other 24 Tour of the ‘HelloWorld’ and the Jenkins user interface 25 Summary page 25 Live build console output 26 Job overview 27 Automatic start of build 28 Jenkins and branches 29 Branching – GitFlow 29 Branches and Jenkins file 30 Multibranch pipeline build and HelloWorld 31 Final Jenkins tips 37 Mission Control Plugin 37 Build Monitor Plugin 38 ThinBackup 38 Job Configuration History 39 Docker support 39 Cpplint support 39 More Jenkins nodes 39 Blue Ocean user interface 39 Rounding off 41 1/42 Introduction In Part 1,a variety of functions in Jenkins were visualized. I this part, we are going to drill below the surface and look at the configuration and use in a Continuous Integration (CI) scenario in which Jenkins supports the development in feature branches. We configure a number of build jobs using the support functions which were visualized in Part 1 (shown below in reduced format). CppCheck, Unit Tests (TAP format) and Code SLOCCount (Source Lines Of Code Count), Valgrind Coverage. analysis For a Linux system, we will then configure Jenkins to do the following: ● Check the source code using the CPPCheck and CPPLint tools which means creating static code analysis to locate basic code errors and deviations from the code standard. ● Run the test unit and visualize the result ● Check how much of the code is covered by the unit test (code coverage) ● Count the number of code lines and visualize the result with gcov. ● Check binaries with valgrind and visualize the result. We only do memory check (Valgrind contains more tools). Finally, a number of tips for distributed installations, etc. are provided. Implementation of all these checks are low-cost and they have been able to detect errors in all projects I have participated in! As is evident from the above description, Jenkins support typically falls into two parts: ● Use of an external tool which is activated by Jenkins 2/42 ● Visualization of the result. Typically, this is carried out via a purpose-built Jenkins plugin. First, some practical aspects and with these a disclaimer: This subject is very comprehensive, and the description following below should be seen as an appetizer – even though it is fully functional. Jenkins can do so much more! Prerequisites The configuration of Jenkins is described below. For that, the source code is loaded into a Git repository. The prerequisite for the examples is that the Git repository described is available – and this includes authentication configured with SSH keys. The private key in the SSH key pair must be available in connection with configuration of Jenkins. A Git server can be created quickly using a finished Docker image, e.g. this one: Https://hub.docker.com/r/jkarlos/git-server-docker/ which also allows authentication with SSH public/private key pairs. Installing Jenkins *** NOTE *** The screenshots are created in a browser with Danish as the main language. Consequently, the Jenkins user interface is mostly in Danish. In some instances, the Danish translation is not available and the browser then lapses back into English – hence the occasional language confusion. Jenkins may be installed in four ways. 1) You can download the war file on the home page: https://jenkins.io/download/. The advantages are that you get complete control of the installation and may regenerate it later on and that you get the most up-to-date version (contrary to many other tools, the Jenkins community is REALLY well organized with regard to dependencies and quality and I have never experienced problems with their latest versions) 2) It can be installed using the package manager which comes with the Linux distro that is to be used (Jenkins is Java based and also runs on Windows, but this is out of scope for the purposes of the present document). The advantage is that the installation is well integrated. Conversely, it is not the latest. In practice this is rarely important though. 3) A finished image may be installed in a cloud solution. The advantage is that you will quickly be up and running. On the other hand, you will drag all sorts of things into the installation. Usually, this will not be the last version either. 4) It is possible to use the “official” Docker image which is maintained by the Jenkins community. Docker is a container technology with some of the same characteristics as a virtual machine – only way faster and less resource intensive – refer to Wikipedia. Docker will have you up and running in no time and it has a very new version. Again, the disadvantage is that it is difficult to get a full understanding of it, the way it is established, which may be a problem in regulated environments (e.g. 3/42 development of medical devices). The Jenkins community maintains two Docker images as described here: https://hub.docker.com/r/jenkins/jenkins/. The use of it is described in Github here:https://github.com/jenkinsci/docker/blob/master/README.md Here, we are going to use the latter version and use one of the authorized Docker images – jenkins lts (long term support). Introduction The following description details the steps on a Linux machine with ‘Opensuse Tumbleweed’ installed. The procedure will certainly be the same in other Linux distributions and in all circumstances it is a prerequisite that Docker is functioning on a Linux machine (you may try to write the command ‘docker version’ in a console to determine this). Below follows a condensed version of the use. Steps 1. Start a console and type ‘docker pull jenkins/jenkins:lts’. This downloads the Docker image to the machine. Screen dump somewhat into the download process of the Docker image ‘jenkins:lts’ 2. Now, go to the Linux user’s ‘HOME’ folder by typing ‘cd +<Enter>. Let the ‘jenkins_home’ folder run by executing the ‘mkdir jenkins_home +<Enter>’ command 3. Start the newly downloaded image with this command: ‘docker run -p 8080:8080 -p 50000:50000 -v $HOME/jenkins_home:/var/jenkins_home jenkins/jenkins:lts’ 4. Jenkins is now available on port 8080 on the machine as illustrated: 4/42 Starting page for Jenkins in a browser. When a Docker container with an image is started, everything in the Docker container is generally ‘read-only’. After a reboot of the container, everything is thus reset. Usually, a connection is created out of the Docker container to the host machine. In the command above, ‘-v $HOME/jenkins_home:/var/jenkins_home’ indicates that the ‘/var/jenkins_home’ folder INSIDE the Docker container must be mapped to ‘$HOME/jenkins_home’ OUTSIDE the Docker container. Items placed in ‘$HOME/jenkins_home’ therefore survive reboots and fortunately this is also true for configuration of build jobs and plugins. The configuration of Jenkins itself is therefore not deleted in connection with a reboot. After start of the Jenkins Docker container, Jenkins is now available in a browser on port 8080. The displayed path, ‘/var/jenkins_home/secrets/initialAdminPassword’, refers to a path inside the Docker container but since ‘/var/jenkins_home’ inside the container is mapped to ‘$HOME/jenkins_home’ outside, we can simply run the ‘cat ~/jenkins_home/secrets/initialAdminPassword’ command to get access to the initial administrator password. 5/42 Listing Jenkins secret at first startup The administrator password is simply pasted into the password field. Clicking ‘Continue’ displays the image for installation of plugins. Just click ‘Install suggested plugins’. As is the case with everything else in Jenkins, this is really well-thought-out. Jenkins then starts installing plugins. Installation of plugins. Select ‘Install Jenkins’ installation of plugins. suggested plugins’ Enter the first user and Jenkins is ready for use. 6/42 Creating the first user Ready for use Proceeding to installation of the necessary external tools. Installing external programs We have chosen to run Jenkins in a read-only Docker image. This means that all the programs we install will disappear next time the Docker container is rebooted. Normally, a custom Docker container is created using a purpose-built Docker file, but this is outside the scope of this document (Googling custom jenkins docker image will produce lots of relevant hits). Below, we are going to install the programs temporarily but the same commands may easily be added to a Docker file which will bring you a long way in the process. To install the programs within the Docker container we need to know its ID. This is retrieved by writing the command ‘sudo docker ps’ in a terminal and read the ID as illustrated below. Identifying the ID for a Docker container. The ID is used in the next sections with the reference <DOCKER ID>. 7/42 In each of the following sections, we will start by entering the Docker container and end by exiting it again. Naturally, this is not necessary, if all the installations are done together. Cppcheck The Cppcheck tool is used to carry out staticcode analysis on the source code. The project is hosted on Sourceforge here: http://cppcheck.sourceforge.net/ This is a tool which carries out a VERY thorough code analysis; its a good idea to add it right from the start to enable developers to rectify findings on an ongoing basis. The project is very active, and there will be a new release approximately every three months.