Issue Lifecycle
Issues are detected automatically.
Statuses
After creation, issues flow through a lifecycle, taking on one of five possible statuses:
Open - set by SonarQube on new issues
Confirmed - set manually to indicate that the issue is valid
Resolved - set manually to indicate that the next analysis should Close the issue
Reopened - set automatically by SonarQube when a Resolved issue hasn't actually been corrected
Closed - set automatically by SonarQube for automatically created issues.
Resolutions
Closed issues will have one of two resolutions:
Fixed - set automatically when a subsequent analysis shows that the issue has been corrected
Removed - set automatically when either the related coding rule or the file is no longer available. The rule may not be available either because it has been removed from the profile or because the underlying plugin has been uninstalled. The file could be unavailable because it has been removed from the project, moved to a different location or renamed.
Resolved issues will have one of two resolutions:
False Positive - set manually
Won't Fix - set manually
Issue workflow
Issues are automatically closed (status: Closed) when:
an issue (of any status) has been properly fixed => Resolution: Fixed
an issue no longer exists 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:
an issue that was Resolved (but Resolution is not False positive) is shown by a subsequent analysis to still exist
Understanding which issues are "new"
To determine the creation date of an issue, an algorithm is executed during each analysis to determine if an issue is new or existed previously. This algorithm relies on line content hashes (excluding whitespace) the issue is reported on. For multi-line issues, we are using the hash of the first line. For each file (after detection of file renaming), the algorithm takes the list of base issues from the previous analysis, and tries to match with raw issues reported by the new analysis. The algorithm tries to first match using the strongest evidence, and then fallback to weaker heuristics.
if the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) > MATCH
detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH
on the same rule, with the same message and with the same line hash (but not necessarily with the same line) > MATCH
on the same rule, with the same message and with the same line number (but not necessarily with the same line hash) > MATCH
on the same rule and with the same line hash (but not the same message and not the same line) > MATCH
Unmatched "base" issues are closed as fixed.
Unmatched "raw" issues are new.
Purging Closed Issues
By default, Closed issues are kept for 30 days. For more details, browse the Housekeeping documentation.