This is a self-assessment activity to give you practice in working with the Jenkins continuous integration system. Feel free to share your problems, experiences, and choices in the Forum.

1. Jenkins and Public Projects

In a previous assignment, you set up a project with an automated build and some unit tests, all controlled by ant. We’ll use that as the starting point for this lab.[1]

1. Create a public project on GitLab and push your project code up to there.

2. On a separate page/tab, log in to Jenkins. Use the “New Item” link to start setting up a new Jenkins project.

   Pick a name and select “freestyle”. Click OK.

3. On the next page, type in an appropriate description.

   Select “Discard old builds” and put in a reasonable limit (3 – 4) on the number of builds to keep.

4. Select Git for the Source code management. Now, because we are working with a public project, Jenkins will not need any special credentials to get a copy of your project. Go back to the page with your GitLab project. Get the HTTP URL for your repository, and enter it as the Jenkins Git URL.

   Wait a few seconds, and you should get a confirmation message indicating that Jenkins was able to find your repository. If not, look carefully at the URL and the message.

5. Skip down to Build Triggers. Select Poll SCM, and enter the timing code

   H/15 * * * *
   

   to check your repository once every 15 minutes. (That’s a bit much in practice, but we won’t be keeping this project around all that long.)

6. For the Build step, indicate that you want to run ‘ant’. Enter the appropriate build target.

   By default Jenkins will look for the build.xml file in the top directory of your repository. But if you have followed the usual Eclipse/git conventions, your build.xml file will be in a directory below that. Click the Advanced... button and enter the actual path to your build.xml file, relative to the top of your repository.

7. Save your project.

8. You could wait 0 – 15 minutes for your project to build, but until you are sure that you have the project set up correctly, it’s easier to use the Build Now link to force an immediate build.

   When the build finishes, clink on it in the Build History and then check the Console Output link. If the build did not run properly, use the info from the console output to adjust your build parameters. (You can edit your project settings by returning to the project page and selecting Configure.)

9. Once your build succeeds, if your build.xml file produces a JUnit report, or Javadoc documentation, try editing your project settings on Jenkins (Configure) and adding a Post-Build Action to publish your report/documentation.

Force another build. You should see a link to your report/documentation appear in the central/main project description area. If you chose JUnit, you should get a “Test Result Trend” graph, which will be a bit boring because one point does not make for much of a trend. But clock in the graph and you will see your detailed test report.

2. Jenkins and Private Projects

Things get a bit trickier if Jenkins needs to supply credentials to GitLab in order to check out your project. This would have been necessary if your project had not been public. But we can simulate this problem by using the ssh URL for your repository instead of the http one.

1. In Jenkins, edit your project settings with the Configure link. Look down where you entered the Git URL. We’ll change this in a moment, but fist click the “Add key” button.

   You should have an ssh key pair that you have been using with GitLab.

   Indicate that you want to supply an “SSH username with Private Key”. Enter the username you use to log into GitLab, then paste in the private portion of your key pair. Click the Advanced... button and enter your passphrase for that key pair.[2]

2. Once you have added that key, change the Git URL you gave to Jenkins ot the ssh address of your project from GitLab. After a few seconds, you should get a confimration that Jenkins was able to access the repository.

3. Save your changes and force another build. Everything should work as before.

4. Wait 15 minutes, and then click the link for the Git Polling Log’ You should see that Jenkins checked your repository, found no changes, and therefore did not bother re-running the build.

5. Try making a small change to your project (maybe break one of your Unit tests so you can see the difference in your test results report), commit and push that change to your GitLab repository, and wait another 15 minutes.

   You should see Jenkins report both the fact that you committed a change, but also you should see a new build in the Build History. Click on it and check the console output and test results.

3. Clean Up

Please delete your Jenkins project (or at least reduce the frequency at which it polls the repository) when you are done.