In part 1 of this article we deployed both GitLab and Jenkins, configured a Git project and connected it to the Eclipse IDE. In this article we will focus on configuring the Jenkins server to work with our GitLab repository and crate a Jenkins job to build our project.
Configuring Jenkins for GitLab
1. Before we can create a job we need to add some plugins to the Jenkins server for GitLab. We need to make sure we have the following plugins installed by going to the Jenkins server, the Manage Jenkins, and then Manage Plugins.
2. Next go to the “Installed” tab to see which if any of the needed plugins are already installed. The plugings that are needed are:
- Git Client Plugin
- Git Plugin
- GitHub API Plugin
- GitHub Plugin
- GitLab Plugin
3. Once you know which plugins you need go to the available tab select the plugins by putting a check in the box to the left of the plugin and selecting install without restart. Once the plugins are installed it may be necessary to check the box to perform a restart of Jenkins. Once completed if you go back to the “Installed” tab you should see the following plugins installed.
4. Now that we have out Git plugins installed we can create a new item by selecting “New Item” from the menu on the left. Once the New Item page loads give your Item a Name and we are going to select a freestyle project and click ok.
5. Once you click ok the item is created and you are taken to the item configuration page. Here you will need to configure a things before we can move forward. You will need the github project URL for this next part so you may want to copy it your clipboard. Put the URL in the “GitHub Project” filed and then under “Source Control Management” select Git and put the URL in the Repository URL field. If your project is not public you will need to perform a number of other steps to get authentication working that I will not cover in this article. Next select Check out to a sub-directory from the “Additional Behaviors” drop down list that says “Add”. Once the dialog shows up enter a name for the subfolder.
At this point you should have pasted the URL for the GitLab project in two areas and inputting a folder name for a local sub-folder.
6. Scroll down to the “Build Section” and from the Add build step drop down menu select “Execute shell”.
7. In the command box we are going to run a basic shell command to zip up the contents of the project into a tar.gz file and place it in the sub-folder that we are using for the project. We are simply going to do the following:
tar -zcvf dailyhypervisor-$BUILD_NUMBER.tar.gz Dailyhypervisor
Notice the use of $BUILD_NUMBER to add the Jenkins build number to the file name. In the above example the “Dailyhypervisor” after the tar command is the folder to place it in.
8. Save the project.
Building the project
Next we are going to run a build of the Jenkins Item we just created to see if it runs successful.
1. On the left side of the screen after you save your Jenknis Item you will see a “Build Now” menu item. Click the “Build Now” menu item and Jenkins will start the build.
If the build completes you will see a blue ball next to it if it was successful, it will be red if it fails.
Now that out manual build was successful we can take it a step further and have a build run every time we push new code to our Git repository. Let’s configure and test:
1. On the left menu click configure for your Jenkins Item. This will open the item so we can edit it. Scroll down to Build Triggers and select “Build when a change is published to GitLab.” On the end of the line is a URL that we will need to put in out GitLab server. Click save when complete.
2. Next we need to go to GitLab, select the project and on the left menu select settings at the bottom of the menu and then click on Web Hooks. Input the URL and seelct Push Events and click “Add Web Hook”.
3. Now go to eclipse make a change to one of your project files, save it, commit it, and push it. Once the push is complete you should see a build automatically run in Jenkins.
So what was the point of all this? Why setup Jenkins to do nothing more than create a tar.gz file on the source project? The point is that we will use the tar.gz in a later article. This is a simple project and we will build on what we are doing here eventually build test cases and other items into the build. For now we have a tar.gz that we will end up publishing to artifactory as an artifact after we actually install code stream. Stay tuned for the Code Stream Installation and Configuration.