Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

SonarQube (SQ) is a static an analysis tool aimed at performing automated code reviews based on static code analysis, and supporting expert reviewers in manual reviews. The GN WP9 T2 team maintains an instance of SQ available at https://sonarqube.software.geant.org and offers software development teams in GÉANT a variety of services based on SonarQube capabilities.In  In the cover folder Software Reviews we describe the types of reviews offered by the WP9 T2 team.

...

After selecting a project, SQ presents a screen with an Overview screen, which provides the core data for each characteristic. These are:

...

For each of these, SQ reports the number of flaws, a rating (from A to E, with A being the highest / "best" score) for this characteristic, and a link to a trend diagram. Each of the reported information can be clicked and directs the user to more detailed analysis and/or diagrams for this value. The definition of the ratings as provided by SQ is described in the Rating table below (as well as, in more detail, at the official SQ documentation).


Table Filter
inversefalse
ddSeparatorsparkNameSparkline
hidePaneTable header
isNewfalse
separatorPoint (.)
labelsMaintainability ratingdefault
ddOperatorcell-width150
userfilterMaintainability rating
datepatternyy-mm-dd
id1643214224199
isORAND
formatVersion2
order0



Reliability ratingSecurity ratingMaintainability rating

Status
colourGreen
titleA

no bugsno vulnerabilitiestechnical debt ratio is less than 5%

Status
colourGreen
titleB

at least one minor bugat least one minor vulnerabilitytechnical debt ratio is less than 10%

Status
colourYellow
titleC

at least one major bugat least one major vulnerabilitytechnical debt ratio is less than 20%

Status
colourRed
titleD

at least one critical bugat least one critical vulnerabilitytechnical debt ratio is less than 50%

Status
colourRed
titleE

at least one blocker bugat least one blocker vulnerabilitytechnical debt ratio is higher than 50%


...

More detailed information is provided by the Issues screen. It presents the list of all issues discovered by SQ, either in the past or currently. On the left-hand side, there are various filters that help in managing the scope of presented issues. Filtering options include the type of issue, its severity, resolution, current status and other information. Please note that the filters are cumulative, i.e., they produce a conjunction of all imposed filters.

Issues presented on the list can be processed by the reviewer, subject to permissions granted to them. By default, reviewers should be able to update the following attributes of the issue:

...

SQ capabilities supporting cross-validation

SQ has a number of built-in capabilities that support performing the manual cross-validation of the issues identified and collected by SQ. For each identified issues ('Issues' tab), the reviewer may:

  • adjust the type of the issue ('Code Smell', 'Vulnerability', 'Bug' - although it is not recommended to alter this value)

...

  • update the severity/priority of the issue ('Info', 'Minor', 'Major', 'Critical', 'Blocker')
  • update the status of the issue ('Confirm', 'Resolve as fixed', 'Resolve as false positive', 'Resolve as won't fix

...

  • ')
  • add a comment
  • add a label/tag

SQ allows for bulk changes to multiple issues (e.g. adding the same tag to multiple issues in one go)

...

.

In addition, SQ reports an estimated remediation effort, showing the time required to adequately address and fix the issue. 

Outline of the proposed procedure

By clicking on an issue, a reviewer can get a contextual description that includes the affected code snippet, with marked subject areas and recommendation provided by SQ rule that identified the issue. For example, code duplications may span across several locations in the code; SQ identifies and marks each of them, so that it is easier to spot them and evaluate their actual impact on the affected quality characteristic.

For each issue reported by SQ (please note that the current view of the issues can be adjusted using filters), the reviewer:

  1. analyzes the issue by inspecting the code in SQ; SQ highlights the code affected by the issue
  2. adjusts the type of the issue (only if it is definitely required!)
  3. updates the priority of the issue (only if it is definitely required!; the reviewer should be particularly cautious when lowering the priority)
  4. validates the status of the issue by setting
    1. 'Confirm', if the issue has been correctly classified by SQ
    2. 'Resolve as fixed', if the issue has been already fixed in the code since the analysis was performed; SQ will close the issue on the next iteration of analysis
    3. 'Resolve as false positive', if the context of the issue indicates that it is invalid, although technically it conforms to the definition of the issue of a given type
    4. 'Resolve as won't fix', if the issue is valid, but does not require fixing (e.g., accepted technical debt)
  5. optionally adds a comment with further details for this issue


Image Added


Upon the next analysis, issues marked as 'Resolve as fixed' will be inspected by SQ again. If the issue is indeed no longer present, SQ will mark the issue as Closed; otherwise, the issue will be Reopened.

Please note that issues marked as 'Resolved' can be reopened by the expert at a later stage. Moreover, other attributes (such as tags) of Resolved issues cannot be updated; the issue needs to be reopened to be further edited.

The person assigned to the issue should not be altered by the reviewer.

Security Hotspots screen

The Security Hotspots screen reports... (TODO: Stefan)This is the basic mechanism for supporting the collaboration of reviewers with SQ. Reviewers are expected to cross-validate the findings reported by SQ by considering the context of the issue.

Measures screen

The Measures screen reports more in-depth data for each quality characteristic and code property (including also size and complexity). This screen provides low-level data and arguments for the issues reported in the Issues screen.

...

By default, SQ presents an overview (a diagram showing the relevance and priority of the issues, and the trend showing changes between consecutive scans made by SQ) and the aggregated lists of analyzed files affected by the specific type of issue. That helps in performing a more thorough analysis, restricted to a specific type of issue, and targeted at uncovering the root cause of it.

Code screen

The Code screen acts as a formatted preview of the recent code snapshot analyzed by SQ, grouped by the packages. The screen also provides also line numbers, the commits that recently changed a given line (including the author, data and commit id). Next, it indicates lines covered by unit tests (in green) and not covered (in red).

...

Activity screen

The Activity screen shows trend diagrams for selected metrics. Trends show how the subject metric(s) changed during subsequent SQ analyses. The data to be presented in the diagram can be customized by selecting the time period and the type of metric.

...