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

Ability to rename a rule key

    XMLWordPrintable

    Details

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

      Description

      WHY

      if we take the example of SonarJava, there are currently two patterns in place for rule keys:

      Obviously, from a end-user perspective, would be better to have only one pattern in place. In fact neither of the two previous patterns is really appropriate. For instance the squid name is not meaningful. So we would for instance prefer something like JAVA:${RSPEC-ID}. By having all the rule keys complying with the same pattern that would also allow us tomorrow to group in the UI the same rule available in different languages.

      Is there anything preventing us from doing this change? Technically nothing, but when a rule key is updated there is a huge blocker side effect: all the existing issues detected by this rule are closed and new ones are created.

      So the need is to be able to rename a rule key as often as we want without losing the existing issues. Moreover, this key renaming mechanism should also support the downgrade of a code analyzer.

      WHAT

      The Sonar API to declare a rule should evolve to be able to attach to a rule a set of old deprecated keys. So changing a rule key should be as easy simply declaring a new deprecated key in this set. These API changes must be validated by someone from the languages team.

      HOW

      The primary key of a rule is already a UUID in the SonarQube back end and so the key provided by the code analyzer is already a secondary functional key. In other words, the SonarQube back end doesn't rely on this functional key to link for instance an issue with a rule: cool!

      The SonarQube back end should evolve to store the set of deprecated functional keys.

      When doing an analyzer upgrade, if a functional rule key stored in the SonarQube back end is declared by the analyzer as deprecated, the functional rule key must be updated in the SonarQube back end.

      When doing an analyzer downgrade, if a functional rule key that us "current" in the analyzer is declared as deprecated in the SonarQube back end, the functional rule key must be updated in the SonarQube back end.

      Each rule key must be unique across both the list of all active rule keys AND the list of deprecated rule keys.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              ann.campbell.2 Ann Campbell
              Reporter:
              freddy.mallet Freddy Mallet (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: