Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info
iconfalse
titleTable of Contents
Table of Contents
maxLevel3
Note

Since version 3.6, the Violations and Reviews concept is replaced by the Issues concept.

In greater detail

Children Display
alltrue

 

While running an analysis, SonarQube raises an issue every time a piece of code does not comply to breaks a coding rule. The set of coding rules is defined through the quality profile associated to with the project. Developers can also manually raise issues  issues that cannot be detected by SonarQube (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 quality issue

Each issue has one of five severities:

  1. BLOCKER
    Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed.
  2. CRITICAL
    Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed. 
  3. MAJOR
    Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ...
  4. MINOR
    Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ...
  5. INFO
    Neither a bug nor a quality flaw, just a finding.

Ideally, the team wouldn't introduce any new issues (any new technical debt). Plugins like Issues Report or SonarQube in Eclipse or SonarQube in IntelliJ can help them as developers because they provide the ability to perform local analyses to check their code before pushing it back to the SCM.But  But in real life, it is 's not always possible or sometimes to code without any new technical debt, and sometimes it's not worth it.

So new issues may be introduced. Then, it is important to review them.in order to keep your technical debt under control. Thus, 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

Browsing Issues

Issues Drilldown

At project level, issues can be browsed through the Issues Drilldown:

Image Removed

Issues Service

At global level, an Issues Service is available to search issues by project, status, assignee, etc:

Image Removed

Displaying Issues Widgets on Dashboards

SonarQubecomes with several widgets that are specialized to display issues information on dashboards. These widgets are grouped in their own Issues category:

Image Removed

By default the "Rules Compliance" widget, displaying the number of issues by severity, is displayed on the main dashboard:

Image Removed

Out of the box, SonarQubecomes with an Issues dashboard displaying some of these widgets:

Image Removed

Reviewing an Issue

To review an issue, you must be logged in and have the 'User' role on the project where the issue stands.

Image Removed

The main available actions are:

  • Starting a thread of discussion
  • Starting a workflow of resolution
  • Marking an issue as false positive
  • Assigning an issue to a developer
  • Changing the severity of an issue
  • Linking an issue to an action plan
  • Viewing an issue change log

Starting a thread of discussion

Image Removed

Starting a workflow of resolution

To make sure that an issue will be reviewed and eventually fixed, you can start a workflow of resolution.

Possible Status: Closed, Confirmed, Open, Reopened, Resolved
Possible Resolution: False positive, Fixed, Removed

Manual workflow (through the web interface)

 

Image Removed

Automated workflow (during analysis)

Issues are automatically closed (status: Closed) when:

  • the issue (that could be of any status) has been properly fixed => Resolution: Fixed
  • the issue does no longer exist because the related coding rule has been deactived or is no longer available (ie: plugin has been removed) => Resolution: Removed

Issues are automatically reopened (status: Reopened) when:

  • the issue that is Resolved (but Resolution is not False positive) is not properly fixed

Making an issue as false positive

To mark an issue as false positive, click on the False positive link.

Note that false positives are not displayed by default on the code viewer. To display them, select False positives in the dropdown list:

Image Removed

If you tend to mark a lot of issues as false positives, 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.

Assigning an issue to a developer

Any issues (whose status is Open or Reopened or Confirm) can be assigned to a developer by clicking on the Assign link.

As issues are fully integrated within the Notification service, developers can receive email notifications when issues are assigned to them, changes are made on issues reported by them, etc. For more details, browse the Notification documentation page.

Changing the severity of an issue

The severity of any issues can be changed by clicking on the Change severity link.

Linking an issue to an action plan

Action plans can be created to group issues. Action plans are buckets of issues that you want to group as they are going to have similar timeframe for resolution.

Action plans can be created by project administrators from Configuration > Action Plans:

Image Removed

Each issue can then be linked to an action plan:

Image Removed

Viewing an Issue change log

The change log of an issue can be displayed by clicking on its creation date:

Image Removed

Creating a Manual Issue

An issue can be created by clicking on the '+' button in the first column of the code viewer:

Image Removed

Note that manual rules have to be previously defined by a System administrator.

 The issue is then displayed within the source code and can be reviewed as any other issues:

Image Removed

Linking an Issue to an External Task Manager

It is possible to link an issue to an external task manager. To link issues to JIRA for example, you can install the SonarQube JIRA plugin.

Purging Closed Issues

By default, Closed issues are kept for 30 days. For more details, browse the Database Cleaner documentation page.

 get introduced. SonarQube's issues workflow can help you manage those issues. By default, there are seven different things you can do to an issue (other than fixing it in the code!): Comment, Assign, Plan, Confirm, Change Severity, Resolve, and False Positive. Plugins may add more options, such as Link to JIRA.

Image Added

These actions break out into four different categories. First up is the "technical review" category.

Technical Review

Confirm, False Positive, and Change Severity fall into this category, which presumes an initial review of an issue to verify its validity. Assume it's time to review the technical debt added in the last review period - whether that's a day, a week, or an entire sprint. You go through each new issue and do one of three things:

  • Confirm - By confirming an issue, you're basically saying "Yep, that's a problem."
  • False Positive - Looking at the issue in context, you realize that for whatever reason, this issue isn't actually an issue, erm... "problem." It's not actually a problem. So you mark it False Positive and move on. It will disappear immediately from drilldown and after the next analysis for issues counts.
  • Change Severity - This is the middle ground between the first two options. Yes, it's a problem, but it's not as bad a problem as the rule's default severity makes it out to be. Or perhaps it's actually far worse. Either way, you adjust the severity of the issue to bring it in line with what you feel it deserves. The marker in the drilldown will change to show the new severity immediately, but the change won't be reflected in your issue counts until after the next analysis.

Dispositioning

Once issues have been through technical review, it's time to decide how you're going to deal them. You've got up to three choices here, and while the technical review options are mutually exclusive (well, mostly), you may find yourself using all three of these on the same issue:

  • Assign - Assign the issue to yourself or a teammate for immediate handling. The assignee will receive email notification of the assignment if he signed up for notifications, and the assignment will show up everywhere the issue is displayed, as well as in certain widgets.

    Image Added

    Image Added

  • Plan - Some issues will need immediate action, but others you might want to put off. The Action Plan functionality lets you group issues into sets, optionally assign dates, and track set resolution. Once you've created an action plan, the Plan option on an issue lets you put the issue into the set.

    Image Added

  • Link to JIRA - Assuming you've installed the JIRA Plugin, this option allows you to create a JIRA ticket for an issue. The URL to the JIRA ticket will be added to the issue and a link to the issue will be added to the JIRA ticket. After that though, there's no relationship between the two. Updating the JIRA ticket won't touch the issue and vice versa.

General

There's only one option under the General category: comment. At any time during the lifecycle of an issue, you can log a comment on it. Comments are displayed in the issue detail in a running log. You have the ability to edit or delete the comments you made.

Image Added

Endgame

If you've been doing the math, you already know that there's only one option left: Resolve. Use this option to signal that you think you've fixed an open issue. If you're right, the next analysis will move it to closed status. If you're wrong, its status will go to re-opened.

So that's it. That's how SonarQube lets you manage issues: by helping you vet them, organize what to fix now and what to schedule for later, and track them as your Plan comes together.

Other