Issue management solution overview

This page explains: how SonarQube identifies, assigns, and synchronizes issues; the issue lifecycle; and the issue-related features and concepts deprecated in this version.

Issue identification and assignment by SonarQube

For each code file:

1. SonarQube checks if the file has been renamed.
2. SonarQube determines:
   • Whether an issue found during the current analysis is new or existed previously.
   • If an issue found during the previous analysis has been fixed. 
3. For each new issue:
   • SonarQube determines and sets the issue date. The issue date is the analysis date except in some cases where issue backdating to the line commit date is necessary.
   • SonarQube tries to automatically assign the issue to an appropriate SonarQube user.

Method used to identify if an issue is new

SonarQube and SonarCloud use the same algorithm to determine whether an issue is new or existed previously:

• For each issue found in the file from the previous analysis, it compares it to each issue found in this file during the current analysis:
  • If there is no match then it considers the issue as Fixed.
  • If there is a match and the issue status is Fixed in the previous analysis then it reopens the issue.
• For each issue found in the file during the current analysis, if there is no matching issue in the file from the previous analysis then it is considered new.

This algorithm relies on the issue's line hash. The line hash is calculated based on the content of the first line the issue is reported on, excluding the white spaces.

The figure below shows the comparison process between two issues.

Issue backdating (new issues raised on old code)

In some corner cases, new issues (issues that didn't exist in the previous analysis) may be detected on old code (code outside of the new code definition period). This may be the case, for instance, if the issue has existed in code for a long time but was only found in the most recent analysis because new rules were added to the quality profile. In such cases, SonarQube doesn't apply the analysis date as the issue date but uses backdating so that it can correctly identify whether the new issue is to be reported on new code or old code (overall code).  

If the date of the last change to the line is available (this requires SCM integration) then SonarQube will backdate  to this date an issue identified as new in the following cases:

• On the first analysis of a project or branch.
• When the rule is new in the quality profile (a brand new rule activated or a rule that was deactivated and is now activated) or when a rule parameter was changed.
• When SonarQube has just been upgraded (because rule implementations could be smarter now).
• When the rule is external (rule managed and applied by an external, third-party analyzer).
• Previously excluded files are now analyzed.

Automatic issue assignment

SonarQube automatically assigns an issue during analysis to the last committer on the issue line - called issue author - if the author can be correlated to a SonarQube user. Otherwise, it assigns the default assignee if a default assignee is configured in SonarQube.

Login and email correlations between SCM account and SonarQube user are made automatically. For example, if the user commits with their email address and that email address is part of their SonarQube user profile, then new issues raised on lines where the user was the last committer will be automatically assigned to the user.

Issue life cycle

An issue can have the following statuses:

• Open: initial value after the first analysis. A user can reopen an Accepted or False positive issue.

• Accepted: set by an authorized user if they
decide to fix the issue later or not fix the issue.

  SonarQube ignores accepted issues in the ratings of the code but displays the number of accepted issues in the various analysis snapshots in the UI.
• False positive: set by an authorized user if the analysis is mistaken.

  SonarQube ignores False positive issues in the quality reports and ratings of the code. 
• Fixed: set by SonarQube after a subsequent analysis if the previously open issue has been fixed in the code (is no longer being detected).
  By default, Fixed issues are purged after 30 days. This is set in Housekeeping. 

The figure below shows the issue life cycle.

Issue synchronization between branches

When you create a new branch, SonarQube transfers the attributes of the issues (status, assignee, change log, comments) from the source branch to the new branch. This way, if you had, for example, marked an issue in the source branch as False positive, this issue will still be marked as False positive in the new branch after its first analysis.

Issue synchronization applies also in case of a merge:

• With pull request: after the merge, SonarQube transfers the attributes of the issues from the pull request analysis to the target branch. 
• Without pull request: if the New Code Definition of the branch to be merged is Reference branch, and the branch is merged into its reference branch, after the merge, SonarQube transfers the attributes of the issues from the branch analysis to the reference branch. 

The figure below illustrates the issue synchronization between branches.

Deprecated features and concepts of the issue management

The following is deprecated:

• The issue type (Bug, Vulnerability, Code Smell).
  Issue types are now tied to Clean Code attributes and to the software qualities they impact (Reliability, Security, and Maintainability):
  • Bugs impact reliability.
  • Vulnerabilities impact security.
  • Code smells impact maintainability.
• The rule severity concept (Blocker, Critical, Major, Minor, Info).
  The rule severity concept has been replaced with a new severity concept which is used to qualify the impact level of a software quality associated with a rule and can take three values: High, Medium, and Low.
  Currently:
  • Issues don't inherit the deprecated rule severity.
  • The deprecated severity of a rule can still be changed within a quality profile.
• Marking an issue as Confirmed, indicating that an issue is valid. 
• Marking an issue as Fixed, indicating that an issue was corrected in the code.