While running an analysis, Sonar raises an issue every time a piece of code does not comply to a coding rule. The set of coding rules is defined through the quality profile associated to the project. Developers can also manually raise issues that cannot be detected by Sonar (examples: the implementation of the method does not comply to the functional requirements, the javadoc of the method does not match its implementation, etc.).
The ideal objective would be for the whole team not to introduce any new violations (any new technical debt). Plugins like Issues Report or Sonar in Eclipse can help them as they provide the ability to perform local analyses to check their code before pushing it back to the SCM.
But in real life, it is not always possible or sometimes not worth it. In order to keep the technical debt under control, issues can be reviewed. Then, your requirement should become something like: any new issue should be reviewed and according to its severity should be either:
- Fixed immediately
- Put in an action plan to be fixed during the next development sprint(s)
- Kept it in mind as a piece of technical debt that does not require a corrective action for now as the return on investment is too low
At Project Level
At project level, issues can be browsed through the Issues drilldown tool.
An Issues Service is available to search issues by project, status, assignees, etc.
To review an issue, you must be logged in and have the 'User' role on the project where the issue stands.
The possible actions on an issue are:
- Starting a thread of discussion
- Starting a workflow of resolution
- Marking it as false-positive
Workflow of resolution
You can assign an issue to a developer.
The wokflow is a follow:
- If correctly resolved, it will be closed by Sonar during the next analysis. If not, it will be automatically reopened.
Manual issues... Closed?
Making an issue as false-positive
To mark an issue a false-positive, click on the False-positive link.
The issue will be closed during the next analysis and will not appear again in the code viewer. Note that you can always browse false-positive issue that are closed in the Issues service.
Once a violation is switched off, this violation is no more displayed by default in the resource viewer. The option "False-Positives only" must be selected to display those false-positive violations:
If you tend to mark a lot of issues as false-positive, it means that some coding rules are not adapted to your context. So, you can either completely deactivate them in the quality profile or use the Switch Off Violations plugin to not check them on specific parts (or types of object) of your application.
!!!!!! Moreover, all measures on the project like the number of violations will be updated the next time a Sonar analysis will run.
Creating Manual Issue
Whenever a quality defect is detected “manually”, the person who detected it has the ability to create a new violation (with its associated review) directly into Sonar.
The related violation is then displayed within the source code and will be accounted for in metrics after the next analysis of the project.
Changing the Severity of a Violation
Linking a Review to an Action Plan
Each review can be linked to an action plan:
Linking a Review to an External Task Manager
It is possible to link a review to an external task manager. To link reviews to JIRA, you can install the Sonar JIRA plugin.
Creating an Action Plan
Action plans can be created to group reviews together. Action plans are buckets of reviews that you want to group as they are going to have similar timeframe for resolution:
Sonar comes with several widgets that are specialized to display reviews information in dashboards. Those widgets are grouped in their own category in the dashboard configuration:
Here is the type of dashboard you can create to manage reviews:
Issues are fully integrated with the Notification service. Notifications can be received when <TOODO>.
For more details, browse the Notification documentation page.