Note: Please treat these exercises also as professional work. For example, instead of "asdfg" use more meaningful commit messages like "Add acceleration feature" or "Fix #5" (you can find detailed advice in the How to Write a Git Commit Message and the Git Style Guide posts).

Initialization

• You should continue with your GitHub repository from the previous lab by creating a local clone. If you did not participate in the previous lab, then you have to complete that lab first.
• In the second part of the lab, you will have to work in pairs (e.g., with someone you know, or you can search in Lab 5 Teams channel).

Static Analysis

The purpose of the first subtask is to perform static analysis with the Sonar tool suite on your repository.

• SonarLint is an IDE extension, which runs the static analyzer during writing source code, and gives immediate feedback about code quality.
• SonarCloud is a code quality management platform, supporting more than 20 programming languages (including Java, C, C++, C#). It can check coding conventions, duplicated code, test coverage, code complexity, potential bugs and vulnerabilities. It stores the results of previous analyses in the cloud, making it possible to produce reports and evolution graphs. It is free for public GitHub repositories.
• SonarQube is an on-premise version of the code quality platform. We will not use it during this lab.

SonarLint

SonarLint can be easily installed in major IDEs. During this lab, we use it in Visual Studio Code.

• Check in Visual Studio Code in the Extensions tab from the left bar that the SonarLint is installed.
• If not, install the SonarLint extension into Visual Studio Code (see here). Restart Code IDE.
• Open your own local ivt-lab folder.
• Open one of the Java files to start the Java extension, which builds your project in the background. If everything goes well, then you can see the build results and warnings in the View / Problems window.
• Select SonarLint in the Output window from the drop-down list on the right to view its logs. You can check which files are currently analyzed.
• Open the TorpedoStore.java file. SonarLint will find three errors. Inspect them, but do not correct them yet.
• If you move the mouse pointer over the error in the code, then you can read a short description of the identified problem. If you select the source line with the problem and click on the light bulb at the beginning of the line, then by clicking Open description of SonarLint rule ... the details of the analysis rule is presented. For every rule, there is a short description and valid and invalid examples.
• Inspect every error and every corresponding rule. Has the static analysis tool identified a valid problem (true positive)?
• Finally, you can browse all active rules in the Rules block of SonarLint in the left bar. Check out a few rules to get an idea about what can be checked with static analysis.

Connecting the GitHub repository to SonarCloud

In this task, you connect your own public repository to the SonarCloud cloud-based code quality platform.

• Open the SonarCloud page, click on Log in. Select GitHub from the login options and sign in with your GitHub account.
• Inspect what privileges are requested by SonarCloud, then authorize SonarCloud.
• On the Welcome to SonarCloud page in the top right corner there is a + sign next to your profile picture. Open it, and the click on the Create new organization link. From the list choose your own personal organization belonging to your account, and install the SonarCloud integration.
• You will be taken back to SonarCloud to finish creating the organization. Choose the Free plan option.
• Click on the Analyze new project link from the home screen, and choose the ivt-lab repository.
  • If the Set up project for Clean as You Code question pops up, choose Previous version.
• On the next page choose Main Branch from the left menu bar to see the result of an automatic analysis. This new feature of SonarCloud gives limited result, so we will not use it during this lab.
• Click on the Setup CI-based analysis button (if it is missing: Administration from the left menu bar, then Analysis Method), and from the possible analysis methods choose the Analyze with a GitHub Action option. Choose Maven from the next screen, and disable the automatic analysis.
• Follow the instructions on the page and add the 2 sonar.* properties to the pom.xml file, add the SONAR_TOKEN secret on the Secrets tab of your own GitHub repository, and extend the Github Actions YAML file with the SonarCloud specific steps (mind the indentation).
  • Hint: to compare the suggested and our current YAML files, copy the suggested YAML config to a New Text File, then View / Command Palette / Compare Active File With... our own YAML file.
• Commit your changes and check the new GitHub Actions build. If it is successful, then you will see the results on the SonarCloud dashboard shortly.
• You can access the analysis results of the main branch or pull requests later on the left menu bar. Choose Main Branch for now.
• Open the result of the analysis, and get to know the SonarCloud interface:
  • Summary: overview of the results and the most important metrics
  • Issues: details about each issue with the corresponding source lines and analysis rule.
  • Measures: details about the metrics presented on the summary page
  • Code: you can browse the full codebase
  • Activity: you can check each run of the tool and the analysis trends
  • More information can be found in the documentation.
• If everything is OK so far, then go to SonarCloud's Activity page, and you should see the new execution.

With the above settings, static analysis will be run on every new commit on the CI server, and it will provide feedback about code quality.

Code Review

The purpose of the second task is to fix some of the issues found by SonarQube and then to review the changes by forming pairs and using the GitHub Pull Request Review feature. The purpose of this feature is to support efficient code review, e.g., by attaching comments to lines of code.

Fixing Issues

1. [local] Switch to a new branch (git checkout -b <name_of_new_branch>).
2. [local] Fix the 3 Bug issues found by SonarLint, each in a separate commit. Make sure to work on the new branch.
3. [local] Push the modifications to the remote GitHub repository (git push).
   • Note, that the new branch does not have a corresponding remote branch. Therefore the push must be executed in the following form: git push --set-upstream origin <name_of_new_branch>.

Review

1. [web] Form pairs. Give permissions to your repository for the other person. This can be done on the web interface of GitHub under the page Settings / Collaborators.
2. [web] If your partner also gave permissions for you, you should receive an e-mail. Click on the View invitation link to accept.
3. [web] Create a pull request in your own repository using the following steps.
   1. [web] Start creating the pull request (PR) on the Pull requests tab with the New pull request button.
   2. [web] The base branch should remain the default master, and for the compare branch, pick your new branch. You should see a label "Able to merge" and your previous commits. Click on Create pull request to continue.
   3. [web] On the next page you can give the details and settings for the pull request. Add a meaningful name and a short description. On the right side assign yourself (Assignees) and request a review from your partner (Reviewers).
   4. [web] Finalize the request with the Create pull request button. Your partner should receive a notification about the requested review.
   5. On the Checks page of the PR you can follow that the CI build has started automatically. Once they finish, you can check the analysis results on the Conversation page.
4. [web] If your partner also followed the previous steps, you should receive a notification about a pull request review. Go to the repository of your partner and find their pull request.
5. [web] Perform the review with the following steps.
   1. [web] Go to the Files changed tab. You can see the files modified by your partner. Review the files and attach comments by clicking on lines. It is important to start adding comments by clicking on Start a review, instead of using Add single comment.
   2. [web] After finishing the review, click on Review changes in the top right corner. Write a short summary and request changes.
   3. [web] Finish the review process by clicking on Submit review.
6. [web/local] Wait until your partner finishes reviewing your pull request. Then fix your code based on the review. The changes should still go to the new branch in one or more commits. After finishing, push the changes to the remote repository (git push).
7. [web] Wait until your partner finishes fixing their code based on your review. Then goo to the pull request of your partner to see the changes on the Files changed tab. Accept the changes by clicking Review changes and Approve.

Analyzing the Changes

1. [web] Check on SonarCloud whether all issues were indeed fixed.
2. [web] If you check SonarCloud, you will see that there is a pending Security issue with your code. The issue relates to the use of Random. Read and consider the What's the risk? and Assess the risk descriptions.
3. [web] Since this code does not have such security aspect, declare the use of Random Safe, and rerun the analysis from GitHub.
4. [web] If your partner also accepted your changes, and all the checks have passed (are green), merge your pull request (at the bottom of Conversation tab).