Lab 1 – Configure Tools in Jenkins

In this lab you will verify that Jenkins Continuous Integration is already installed and you will configure it.

At the end of this lab you will be able to:

1. Verify Jenkins is running

2. Configure tools in Jenkins

Part 1 – Configure Jenkins

After the Jenkins installation, you can configure few other settings to complete the installation before creating jobs. You will be setting JDK HOME and Maven Installation directory.

1. To connect to Jenkins, open Firefox and enter the following URL .


2. Enter wasadmin as user and password and click Log in.

3. Don’t save the password if prompt or select Never Remember password for this site.

4. Click on the Manage Jenkins link.

Continuous Integration

5. Click Global Tool Configuration.

6. Scroll down and find the JDK section, Click Add JDK.

7. Enter OracleJDK for JDK name.

8. Don’t check the ‘Install automatically’ option. Uncheck if already checked.

9. Enter JAVA_HOME value as C:Program FilesJavajdk1.8.0_45

Note. You may need to use another path if Java was installed in a different folder, contact your instructor or search for the right path and use it as JAVA_HOME.

10. Verify your settings look as below:

11. In the Maven section, click Add Maven.

12. Enter Maven for Maven name.

13. Uncheck the ‘Install automatically’ option.

14. Enter C:Softwareapache-maven-3.3.9 for MAVEN_HOME. Make sure this folder is correct.

15. Verify your settings look as below:

16. Scroll down and click Save.

Part 2 – Review

In this lab you configured the Jenkins Continuous Integration Server.

Lab 2 – Create a Jenkins Job

In this lab you will create and build a job in Jenkins. Jenkins supports several different types of build jobs. The two most commonly-used are the freestyle builds and the Maven 2/3 builds. The freestyle projects allow you to configure just about any sort of build job, they are highly flexible and very configurable. The Maven 2/3 builds understand the Maven project structure, and can use this to let you set up Maven build jobs with less effort and a few extra features.

At the end of this lab you will be able to: Create a Jenkins Job that accesses a Git repository.

Part 1 – Enable Jenkins’ Maven Plugin

1. Go to the Jenkins console:


2. Click on the Manage Jenkins link

3. Click on Manage Plugins

4. Click on the Available tab.

5. In the filter box at the top-right of the window, enter ‘maven’. Note: Don’t hit Return!

6. Entering the filter text will narrow down the available plugins a little. Scroll down to find the ‘Maven Integration Plugin’ listing, and click on the checkbox next to it.

7. Click on Install Without Restart.

8. Click on Go back to the top page.

Part 2 – Create a Git Repository

As a distributed version control system, Git works by moving changes between different repositories. Any repository apart from the one you’re currently working in is called a “remote”
repository. Git doesn’t differentiate between remote repositories that reside on different machines and remote repositories on the same machine. They’re all remote repositories as far as
Git is concerned. In this lab, we’re going to start from a source tree, create a local repository in the source tree, and then clone it to a local repository. Then we’ll create a Jenkins job that pulls the source files from that remote repository. Finally, we’ll make some changes to the original files, commit them and push them to the repository, showing that Jenkins automatically
picks up the changes.

1. Open to the folder C:LabFilesCreate A Jenkins Job

2. Right click in the empty area and select Git Bash Here. The Git command prompt will open.

3. Enter the following command:


4. Enter the following lines. Press enter after each line:

git config –global “” git config –global “Bob Smith”

The lines above are actually part of the initial configuration of Git. Because of Git’s distributed nature, the user’s identity is included with every commit as part of the commit data.
So we have to tell Git who we are before we’ll be able to commit any code.

5. Enter the following lines to actually create the Git repository:

git init git add .
git commit -m “Initial Commit”

The above lines create a git repository in the current directory (which will be C:LabFilesCreate a Jenkins JobSimpleGreeting), add all the files to the current commit set (or ‘index’ in git
parlance), then actually performs the commit.

6. Enter the following, to create a folder called repos under the C:Software folder.

mkdir /c/Software/repos

7. Enter the following to clone the current Git repository into a new remote repository.

git clone –bar . /c/Software/repos/SimpleGreeting.git

At this point, we have a “remote” Git repository in the folder C:SoftwarereposSimpleGreeting.git. Jenkins will be quite happy to pull the source files for a job from this repo.

Part 3 – Create the Jenkins Job

1. Go to the Jenkins console:


2. Click on the New Item link.

3. Enter SimpleGreeting for the project name.

4. Select Maven Project as the project type.

5. Click OK, to add a new job.

After the job is created, you will be on the job configuration page.

6. Scroll down to the Source Code Management section and then select Git.

7. Under Repositories, enter C:SoftwarereposSimpleGreeting.git

8. Click the Tab key in your keyboard.

9. Click Save.

10. You will see the Job screen. Click Workspace.

11. Click Build Now.

You should see the build in progress in the Build History area.

12. After a few seconds the build will complete, the progress bar will stop. Click on Workspace.

You will see that the directory is populated with the source code for our project.

13. Find the Build History box, and click on the ‘time’ value for the most recent build. You should see that the build was successful.

14. Click the Console Output from the left menu.

15. At the end of the console you will also see the build success and successful build finish.

You have created a project and built it successfully.

Part 4 – Enable Polling on the Repository

So far, we have created a Jenkins job that pulls a fresh copy of the source tree prior to building. But we triggered the build manually. In most cases, we would like to have the build triggered automatically whenever a developer makes changes to the source code in the version control system.

1. In the Jenkins web application, navigate to the SimpleGreeting project. You can probably find the project in the breadcrumb trail near the top of the window. Alternately, go to the
Jenkins home page and then click on the project.

2. Click the Configure link.

3. Scroll down to find the Build Triggers section.

4. Click on the checkbox next to Poll SCM, and then enter ‘* * * * *’ into the Schedule text box. [Make sure there is an space between each *]

Note: The above schedule sets up a poll every minute. In a production scenario, that’s a higher frequency than we need, and it can cause unnecessary load on the repository server and on the
Jenkins server. You’ll probably want to use a more reasonable schedule – perhaps every 15 minutes. That would be ‘H/15 * * * *’ in the schedule box.

5. Click Save.

Part 5 – Import the Project into Eclipse

In order to make changes to the source code, we’ll clone a copy of the Git repository into an Eclipse project.

1. Start Eclipse by running C:Softwareeclipseeclipse.exe and use C:Workspace as Workspace.

2. Close the Welcome page.

3. From the main menu, select File → Import…

4. Select Git → Projects from Git.

5. Click Next.

6. Select Clone URI and then click Next.

You might think that ‘Existing local repository’ would be the right choice, since we’re cloning from a folder on the same machine. Eclipse, however, expects a “local repository” to be a working directory, not a bare repository. On the other hand, Jenkins will complain if we try to get source code from a repository with a working copy. So the correct thing is to have Jenkins pull from a bare repository, and use Clone URI to have Eclipse import the project from the bare repository.

7. Click on Local File… and then navigate to C:SoftwarereposSimpleGreeting.git

8. Click OK.

9. Back in the Import Projects dialog, click Next.

10. Click Next to accept the default ‘master’ branch.

11. In the Local Destination pane, leave the defaults and click Next.

12. Select Import as a General Project and click Next.

13. Click Finish.

14. You should see the new project in the Project Explorer, expand it.

At this point, we could go ahead and edit the files, but Eclipse doesn’t understand the project’s layout. Let’s tell Eclipse what we know – that this project is built using Apache Maven.

15. Right-click on the SimpleGreeting project in the Project Explorer, and then select Configure → Convert to Maven Project.

16. After few seconds, you should now see the project represented as a Maven project in the Project Explorer.

Part 6 – Make Changes and Trigger a Build

The project that we used as a sample consists of a basic “Hello World” style application, and a unit test for that application. In this section, we’ll alter the core application so it fails the test, and then we’ll see how that failure appears in Jenkins.

1. In the Project Explorer, expand the src/main/java tree node.

2. Expand the com.simple package to reveal the file.

3. Double-click on to open the file.

4. Find the line that says ‘return “GOOD”;’. Edit the line to read ‘return “BAD”;’

5. Save the file by pressing Ctrl-S or selecting File → Save.

Now we’ve edited the local file. The way Git works is that we’ll first ‘commit’ the file to the local workspace repository, and then we’ll ‘push’ the changes to the upstream repository. That’s
the same repository that Jenkins is reading from. Eclipse has a short- cut button that will commit and push at the same time.

6. Right-click on SimpleGreeting in the Project Explorer and then select Team → Commit…

7. Enter a few words as a commit message, and then click Commit and Push.

8. Click OK in the status dialog that pops up.

9. Now, flip back to the web browser window that we had Jenkins running in. If you happen to have closed it, open a new browser window and navigate to http://localhost:8080/SimpleGreeting.
After a few seconds, you should see a new build start up.

10. If you refresh the page, you should see that there is now a ‘Test Result Trend’ graph that shows we have a new test failure.

What happened is that we pushed the source code change to the Git repository that Jenkins is reading from. Jenkins is continually polling the repository to look for changes. When it saw that
a new commit had been performed, Jenkins checked out a fresh copy of the source code and performed a build. Since Maven automatically runs the unit tests as part of a build, the unit test was run. It failed, and the failure results were logged.

Part 7 – Fix the Unit Test Failure1. Back in eclipse , edit the file so that the class once again returns ‘GOOD’.

2. As above, save, commit and push the change.

3. Watch the Jenkins web browser window. After a minute or two you should see the build start automatically, when the build is done then refresh the page.

Part 8 – Review

In this lab you learned
• How to Set-up a set of distributed Git repositories
• How to create a Jenkins Job that reads from a Git repository
• How to configure Jenkins to build automatically on source code changes.

Lab 3 – Add Development Metrics

We are going to integrate code coverage metrics using the Cobertura plugin. Code coverage is an indication of how much of your application code is actually executed during
your tests—it can be a useful tool in particular for finding areas of code that have not been tested by your test suites. It can also give some indication as to how well a team is applying good testing practices such as Test-Driven Development or Behavior-Driven Development.

At the end of this lab you will be able to:
1. Install the Jenkins Cobertura Plugin
2. Configuring build tools
3. Run the code coverage without Jenkins

Part 1 – Install the Jenkins Cobertura Plugin

1. Make sure Jenkins is started. Since we configured as windows service it will be started every time you start the machine.

2. Go to the Jenkins console at:


3. To install a new plugin, click Manage Jenkins on the left.

4. Click on the Manage Plugins entry.

5. Click on Available tab.

6. Type cobertura in the Filter and then check the check-box next to Cobertura Plugin.

7. Click on the Download now and Install after restart button at the bottom of the screen.

8. Select the checkbox for Restart Jenkins….

At this point, Jenkins should restart itself. If it doesn’t return to the main screen within a few minutes, you may need to use the ‘Services’ portion of the Windows Control Panel to restart the service manually. Consult your instructor in case of difficulty.

9. If ask to login use wasadmin for user and password.

10. Click Back to Dashboard.

Part 2 – Enable Jenkins Reporting

In this section, we’ll configure Jenkins to publish the Cobertura coverage report, and then we’ll add coverage testing to the project itself.

1. Click on the job we created for SimpleGreeting.

2. On the left-hand menu, click Configure.

3. Scroll down to the Post-Build Actions section.

4. Click on the Add post-build action button and then select Publish Cobertura Coverage Report.

5. Enter the following for the Cobertura XML Report Pattern


6. Scroll up to find the Build section.

7. In the Goals and Options text box, enter the following:

clean install cobertura:cobertura

8. Click Save.

You will see the project screen view and Coverage Report is activated shown as below:

Now lets update the SimpleGreeting Project pom file in Git to handle report metrics.

9. Open Eclipse.

10. In the Project Explorer, navigate to the SimpleGreeting project.

11. Double-click on the file pom.xml to open it.

12. On the lower edge of the editor panel, click on pom.xml to select the XML view of the file.

13. Add the text that is shown in bold text below (the ‘plugin’ and ‘reporting’ sections).


14. Save and close the file.

Next you will Commit and push the changes using the procedure in the previous lab.

15. Right-click on SimpleGreeting in the Project Explorer and then select Team → Commit…

16. Enter a few words as a commit message, and click Commit and Push. Then click OK.

17. Back in the Jenkins page, you should see a build launched within a minute or two. If you don’t see an automatic build, click the Build Now to kick off a manual build.

18. Once the build is completed, move the mouse over the build number window and make check that it is successful:

Note, Build # may vary depending on how many times you build.

19. Now let’s click on the Coverage Report.

You will see the coverage report:

Part 3 – Review

In this lab:
• Learned how to configure a Maven build to report code coverage
• Learned how to report and track that coverage in a Jenkins job.