Continuous Integration Workflow

4.2 Jenkins Overview

Hi, and welcome back to continuous integration workflow. In this lesson, we will set up Jenkins and have a look at the interface. Let's start by creating a new job at Jenkins. I call it tutsplus-continuous-integration. And choose the Freestyle project type. This is the one you want to use most times. It is very flexible in its configurability. If you want to test your project on many different configurations like in a matrix, choose Multi-configuration project. You will then be presented with the main configuration screen for a job. We will skip that for now and look at it later. The main dashboard will show the build status of all your jobs, including a weather map that tells you how your builds are running. Let's delete the project for now and go to the configuration section. If no security is set up, you will get a warning that you have insecure settings and should set up some global security. If you choose to enable security, you will get presented with a variety of ways to do so. We will choose Jenkins' own user database. Right now, it's important that you enable Allow users to sign up. Under authorization, choose Matrix-based security. This gives you a lot of control what each user can do. It is also very important that you add your user that you will create in a minute to the matrix. Otherwise, you will be logged out of Jenkins. Then you need to enable all of the buttons. At the end of the table is a mark all button that inverses your current selection. Enabling CSRF protection also doesn't hurt. Again, make sure you have user sign up enabled, and added your username to the matrix. Then click Save. You will get to the log-in form, and below, you can sign up for a new account. Here you have to use the username you entered in the authorization section. After signing up, you will be automatically logged in. Now, you can go back to the global security configuration and disable sign up. Next up is the plugin section. Jenkins is very extensible and features a wide range of community-created plugins. You can also filter the list with the search field on the top right. For our use case, we will need the GitHub plugin. We also need the GIT client plugin. Then I'll install them without restart. Jenkins will also install all dependencies. Since some plugins need Jenkins to be restarted, I can check the restart option below. After the server restarted, I'll have to log in again. In the list of installed plugins, you can now see that they're indeed installed. We'll also need some plugins for Ruby. First Rvm, and then Rake, so we can run Rake tasks. With everything installed, we can recreate the job. The settings look a little bit different as well. Those plugins added more options. For example, a GitHub project. If you are ever unsure of what to put into a field, there is a question mark next to it that explains what this field is supposed to hold. In the Source Code Management section, you also have to set up Git and use the URL there. Jenkins also has a live verification feature where you get immediate feedback. In our case, there is a Git error. Well, we installed all the necessary plugins, but it doesn't mean that we have Git or RVM already installed in the machine itself. We need to do that manually through the shell. I already know that we will need build tools and PostgreSQL as well. So I will install them too. Since we are already in the shell, let's load the configuration steps for RVM and Postgres right now. I will need to switch to the user that runs the Jenkins server, which I can easily find out by inspecting the processes. In this case, it's the jenkins user. After switching to it, I can install RVM. Now, RVM features GPG signature checking of the packages if the software for it is installed. So we have to import the key first. Luckily, the command is right on the screen. Now, we can install our VM, well, almost. You need to set a password for the Jenkins user and also allow it to run sudo, since it needs to get some packages to install Ruby. The easiest way to allow sudo for Jenkins is to add it to the sudo group. Finally, the RVM installation runs. Now we only need the development headers for Postgres, and we're good to go. After changing the git URL, it doesn't show any more errors. Since it's a public repository, you don't need any credentials. But you could most certainly add them if you'd like. We also want to use an RVM environment to run our builds in. In our case, we'll use the default Ruby and the tutsplus-ci GEMSET. Finally, we need to invoke a Rake task to actually do something. We want to run Rake spec, so we just put spec here and use bundle exec to do so. After saving, we are redirected to the dashboard. You can see there are no builds here. When I press Build Now, a new build gets scheduled. It starts to run, but fails quite quickly. You can see all sorts of details for a build, but the most important one is probably the output. This gives you the most information of what went wrong. In our case, bundler wasn't found. Of course, nobody installed it. We can change our build configuration to include a shared script before the Rake task. It will install bundler and also the bundler gems. After saving, we can run the build again. When a build is still running, you can watch the output live. Bundle installs, seems to run fine. But running the Rake task fails again, because it can't find bundler. It seems in the configuration there is some mistake. Right, I didn't set the correct environment for the rake task. A third build, and now it's succeeded. This is an earlier version of the project without any tests yet. When we have a look at the dashboard again, we can see the build status is a blue dot, which indicates a successful build. The weather map is a rainy cloud since two of the three builds failed. You can also see a runtime and the time since the last failure and success. In the next lesson, I will show you how to properly test a Ruby project with Jenkins. See you there.