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.

...

SQ analyzes the software projects with respect to five main quality characteristics and their corresponding flaws:

  • reliability (bugs)
  • vulnerabilities
  • security (vulnerabilities)hotspots
  • maintainability (technical debt and code smells)
  • code coverage
  • duplications

...

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

  • bugs, vulnerabilities, and security hotspots
  • code smells
  • coverage
  • duplications

of the characteristics described above.

The Overview screen lets one choose between the New Code tab and the Overall Code tab. Perhaps most importantly the Quality Gate Status (Passed or Failed) is being displayed in the top left corner. According to the official SQ documentation "a Quality Gate is a set of Boolean conditions based on measure thresholds against which projects are measured." Threshold examples are "No new blocker issues", "Code coverage on new code greater than 80%", ... Only if all conditions are met, the Quality Gate will be passed. Since the conditions can be freely adjusted, SQ allows to customize Quality Gates to developers' needs.

Image AddedImage AddedImage Removed

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
ddSeparatorddOperator
inversefalse
sparkNameSparkline
hidePaneTable header
isNewfalse
separatorPoint (.)
labelsMaintainability ratingdefault
cell-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%



SQ reports separately the overall numbers and the values for new code (i.e., for the code developed since previous analysis in SQ). That helps in getting the general insight into the project status, and tracking the trends.

On the right-hand sideAt the bottom of the screen, SQ presents the log of its analysis and a small diagram showing all relevant trends in all analyzed versions of the  subject project.

...

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.

Image Removed

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:

Image Added

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' - type: Bug, Vulnerability, Code Smell (although it is not recommended to alter this value)
  • severity: Blocker, Critical, Major, Minor, Info; please note that changes in severity may affect the rating of the project
  • 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', 'status: Open, Confirm, Resolve as fixed, Resolve as false positive, Resolve as won't fix; descriptions of the statuses are provided here')
  • assign the issue to a developer
  • add a comment
  • add a label/tags

SQ allows for bulk changes to multiple issues (e.g. adding the same tag to multiple issues in one go)Users can also comment on the issue and assign labels/tags to it. The recommendations on how to use these elements are provided here.

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

According to the official SQ documentation a "Security Hotspot highlights a security-sensitive piece of code that the developer needs to review. Upon review, you'll either find there is no threat or you need to apply a fix to secure the code."

The Security Hotspots screen reports all the security hotspots identified by SQ along with detailed explanations. Initially, every hotspot has a status of "To review". For each security hotspot the developer has to review the issue and manually change the status to

  • Fixed (after the code has been modified accordingly), or
  • Safe (if the code is not at risk and thus doesn't need to be modified)

Image AddedThis 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.

Image Removed

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.Image Added

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).

Image RemovedImage Added

Image RemovedImage Added

The top-right corner provides also a condensed information about the file size, number of issues linked to currently open file and the test coverage metric (showing how completely the unit tests exercise the code in this file).

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.

Image RemovedImage Added