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.

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. 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.

4. I prefer that people not run builds on the Jenkins server itself (to avoid clogging the server if someone submits a particularly lengthy build or, worse, tests that get caught in an infinite loop). Instead, we want to use separate “runner” nodes whenever possible. Look down a little and check the box “This build is parameterized”.

   Click “Add Parameter’ and select ”Node“. For the default node, use any of the ”runner“ nodes. For the possible node lists, select ”All Nodes". (This allows Jenkins to switch to a different runner if the default one is tied up.)

5. 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.

6. 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.)

7. 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.

8. Save your project.

9. 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.)

10. 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.

1. On Jenkins, take note of the URL for your project, e.g., ‘http://forge350.cs.odu.edu:8080/job/projectName/’

2. Edit your Gitlab project settings,

   • Change the visibility to private.
   • Add a new Developer, named “jenkins.ci”.
   • Under “Web hooks”, select “Push events”, then add a web hook of the form ‘http://forge350.cs.odu.edu:8080/job/projectName/buildWithParameters?token=XXX’
     • The first part of this is the URL you recorded in step 1. Then we add the /buildWithParameters command to that.
     • Choose a simple password for the token XXX.
     • You may need to encode any blanks or other special characters in your project name using % codes. For example, blanks in your project name would be replaced by %20.

3. Edit the Configuration settings of your Jenkins project.

   • For the Git repository URL, use the ssh: URl of your GitLab project.

     • This must start with ssh://, i.e., ssh://git@forge350.cs....

     • Gitlab sometimes puts a colon (‘:’) between the machine name and the start of the path in the ssh URL. If you see that, change it to a ‘/’.

     • For example, if GitLab says that the ssh URL of your project is git@forge350.cs.odu.edu:jdoe/projectName.git, you should give that to jenkins as ssh://git@forge350.cs.odu.edu/jdoe/projectName.git

   • Just under that URL, for “Credentials” select jenkins.ci.

   • Change the “Build Triggers” setting to “Trigger Builds remotely”. For the authentication token, enter the password/token you chose in the prior step.

   Save your configuration changes in Jenkins.

4. 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 and Gitlab projects for this lab when you are done.

© 2015-2016, Old Dominion Univ.