Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-141

Built-in support of "Code Smell", "Bug" and "Vulnerability" issue types in SonarQube

    XMLWordPrintable

    Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Labels:

      Description

      Up to now, the SonarQube UI was really focused around the concepts of "Technical Debt", "Maintainability Level", "Quality Issues", ... because this is what the SonarQube ecosystem was designed for from the beginning. But now, most of the analyzers are also able to detect some bugs and security vulnerabilities. The goal of this MMF is to make it obvious for any user that SonarQube can be used to manage bugs and vulnerabilities along with code smells (i.e. quality issues) and so that SonarQube fully supports out-of-the-box the new SonarQube Quality Model (see MMF-184).

      New types for rules and issues

      Rules and Issues in SonarQube must now have one of the following 3 types:

      • Code Smell
      • Bug
      • Vulnerability

      Rules

      In the API, it should be now possible to define the type of a rule. If this information is not available during the rule sync at startup (because the language plugin has not been updated), then the type of a rule is defined by the following logic based on its tags:

      • if the rule has the "bug" tag => type is "Bug"
      • if the rule has the "security" tag => type is "Vulnerability"
      • if the rule has both tags => type is "Bug"
      • it the rule has none of those tags => type is "Code Smell"

      In any case (type given by the API of deduced from the tags), the "bug" and "security" tags should not be pushed to the backend.

      • This implies that these tags should be ignored during the startup sync
      • This also might imply that a migration is needed to remove those tags on the rules (if the migration for issues is based on rule information - see below)

      The type of a rule cannot be changed by a user. It can only be changed at startup sync if a new version of the corresponding plugin changes its definition or its tags (and in that case, it is not expected that the issues previously created for this rule are updated to reflect this change).

      Issues

      When an issue is created, it inherits the type of the rule it originates from.

      A migration must be run in order to:

      • update all existing issues and set them the appropriate type (= the one of their rule)
      • remove the "bug" and "security" tags

      The type of an issue can be changed at any point of time by a user.

      Metrics

      Impacts on the way to compute existing metrics

      • Only code smells should impact the "technical_debt" and "technical_debt_ratio"

      New metrics

      • "code_smells" and "new_code_smells"
      • "bugs" and "new_bugs"
      • "vulnerabilities" and "new_vulnerabilities"
      • "reliability_rating"
      • "reliability_remediation_effort"
      • "security_rating"
      • "security_remediation_effort"

      Metrics to be updated

      • "SQALE Rating" (sqale_rating) should become "Maintainability Rating" (maintainability_rating)
      • "Effort to rating A" (effort_to_reach_sqale_rating_X) should become "Effort to Reach Maintainability Rating X" (effort_to_reach_maintainability_rating_X)

      New metric domains

      • Maintainability
        • code_smells
        • new_code_smells
        • maintainability_rating (= previously "sqale_rating")
          • "sqale_rating" can be renamed because we don't need to keep history on it
        • technicaldebt_ratio (= previously "sqale_debt_ratio")
          • Note: if we can't rename "sqale_debt_ratio" into "technicaldebt_ratio", let's keep "sqale_debt_ratio" for the moment
        • technicaldebt_ratio_on_new_code (= previously "new_sqale_debt_ratio")
          • Note: if we can't rename "new_sqale_debt_ratio" into "technicaldebt_ratio_on_new_code", let's keep "new_sqale_debt_ratio" for the moment
        • maintainability_remediation_effort (= previously "sqale_index")
          • Note: if we can't rename "sqale_index" into "maintainability_remediation_effort", let's keep "sqale_index" for the moment
        • new_maintainabilty_remediation_effort (=previously "new_technical_debt")
          • Note: if we can't rename "new_technical_debt" into "new_maintainability_remediation_effort", let's keep "new_technical_debt" for the moment
        • effort_to_reach_maintainability_rating_a
      • Reliability
        • bugs
        • new_bugs
        • reliability_rating
        • reliability_remediation_effort
        • new_reliability_remediation_effort
        • effort_to_reach_reliability_rating_a
      • Security
        • vulnerabilities
        • new_vulnerabilities
        • security_rating
        • security_remediation_effort
        • new_security_remediation_effort
        • effort_to_reach_security_rating_a

      Metric domains to be deleted

      • Technical Debt
      • SQALE

      Impacts on existing features

      Rules page

      • Creation of a new "Type" facet containing the three types "Code Smell", "Bug" and "Vulnerability"
      • On a rule description the type should appear before the "severity", "tags", ... fields and it should be possible to change this type
      • The "Type" facet should not open by default (but not anymore the "Tag" facet)

      Note that the "bug" and "security" tags should not appear in the "Tags" facet as they are not supposed to be pushed to the backend.

      Issues page

      • Creation of a new "Type" facet containing the three types "Code Smell", "Bug" and "Vulnerability"
      • The "Type" facet should be open by default and displayed at the top of the list of facets
      • The "Severity" facet should be closed by default
      • On a issue description
        • The type should appear before the "severity", "status", ... fields and it should be possible to change this type.
        • The "Similar Issues" filtering mechanism should also be updated to support this issue type.
        • "debt" should be renamed "effort"
      • On an issue changelog
        • "Technical Debt changed to XXX" should be updated to "Effort changed to XXX"
      • The "Bulk Change" on issues must allow to change the issue type
      • The "Debt" switch button should be renamed "Effort"

      Note that the "bug" and "security" tags should not appear in the "Tags" facet as they are not supposed to be pushed to the backend.

      Quality Profile page

      • On a QP, display the distribution of rules according by type.
        • Example: 34 activated rules (4 vulneratiblity detection rules, 20 bug detection rules, 10 code smell detection rules)

      Default built-in Quality Gate

      • Replace the "no new blocker issues" and "no new critical issues" criteria by "no new bugs" and "no new vulnerabilities"

      Code/Projects pages

      • The columns displayed in the "Code" and "Projects" pages should become : Bugs, Vulnerabilities, Code Smells, Coverage %, Duplications %

      Project Home page

      • Create at the top of the page a new "Bugs && Vulnerabilities" section (or two dedicated sections)
        • Total numbers of bugs and vulnerabilities
          • Background colors depending on the severity of the worst issues (see MMF-184)
        • Leak Period: New bugs and vulnerabilities
      • "Technical Debt" section -> rename it "Code Smells"
        • Replace "issues" by "code smells" and "New issues by "New code smells" (not just a renaming but really by using new metrics)
      • Find a UX way to make it obvious the "Coverage" and "Duplications" sections contribute to the "Maintainability" level of the application.

      "Technical Debt" sub-page

      • Rename it "Code Smells"
      • Replace the number of "Issues" by the number of "Code Smells"
      • Add the "Effort to Reach Maintainability Rating A" close to the "Maintainability Rating"
      • Remove the number of added/removed issues/blocker issues/ ... and "replace" that by an histogram of "New Code Smells" (Last Year filter selected by default)
      • Remove "Unmanaged Issues" widget -> advanced use case for which the "Issues" page must be used
      • Remove cloud of "tags" widget -> advanced use case for which the "Issues" page must be used
      • Remove widget displaying the number of "False-Positive issues", "Open issues", "Reopened issues" -> advanced use case for which the "Issues" page must be used
      • Top 10 of "Code Smell detection rules" with greatest number of code smells
      • History Chart, only the metrics part of the "Maintainability" domain should be available
        • Code Smells
        • Technical Debt
        • Technical Debt Ratio
        • Maintainability Rating

      "Coverage" and "Duplications" sub-pages

      • Move them into the "Maintainability" sub-page (sub-page of sub-page) ?

      New UI features

      New "Bugs" sub-page

      • Total number of bugs
      • Reliability Rating (see MMF-184)
      • Total number of bugs per severity
      • Top 10 of "Bug detection rules" with greatest number of bugs
      • Histogram of "New Bugs" (Last Year filter selected by default)
      • Buble chart of files (projects at view level)
        • X : lines of code
        • Y : issues
        • Size : bugs
        • Color: at least one critical bug (red), at least one major bug (orange), one minor bug (yellow) (see MMF-184 for the color/rating)
      • TreeMap
        • Size : lines of code
        • Color : see above

      New "Vulnerabilities" sub-page

      • Total number of vulnerabilities
      • Security Rating (see MMF-184)
      • Total number of vulnerabilities per severity
      • Top 10 of "Vulnerability detection rules" with greatest number of vulnerabilities
      • Histogram of "New Vulnerabilities" (Last Year filter selected by default)
      • Buble chart of files (projects at view level)
        • X : lines of code
        • Y : issues
        • Size : vulnerabilities
        • Color: at least one critical vulnerability (red), at least one major vulnerability (orange), one minor vulnerability (yellow) (see MMF-184 for the color/rating)
      • TreeMap
        • Size : lines of code
        • Color : see above

      Impacts on the plugin API

      • Rules
        • Plugins must be able to set the type of a rule (Java API or XML file)
      • Issues
        • From a server perspective:
          • Issue#debt should be deprecated in favour of Issue#effort
          • There must be a way to get the issue type
        • From a scanner perspective:
          • Issue#effortToFix now becomes a bit unclear: the "effort to fix" provided by plugins is used by the platform to compute the "effort" (previously "debt"). We might need to find a better name.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              fabrice.bellingard Fabrice Bellingard
              Reporter:
              fabrice.bellingard Fabrice Bellingard
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: