Uploaded image for project: 'Minimal Marketable Features'
  1. Minimal Marketable Features
  2. MMF-1445

SonarLint for Visual Studio - Drop the concept of module

    Details

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

      Description

      WHY

      As described in MMF-365, we’ve decided to stop supporting modules in our ecosystem: SonarQube, SonarCloud and SonarLint.
      SonarLint for Visual Studio must be ready to properly work without modules before those ones disappear from SonarQube and SonarCloud.

      WHAT

      SonarLint for VS periodically fetches issues flagged as won't fix/false positive in SonarQube/SonarCloud in order to prevent these closed issues from being displayed in the IDE.
      The projects attached to a VS solution are currently considered as modules in SonarQube, and SonarLint relies on these modules to map the issues that are found in the IDE with the ones from the server. Since modules will fade away, the approach to match issues should be adjusted/redesigned to work without modules.

      Remote issues are not persisted but fetched again when the user opens a solution and on a periodic basis. Since upgrading SonarLint requires VS to be restarted, we can expect the new file to apply without any impact on the user experience.

      Dropping the support for modules with existing versions of SonarQube might not be worth the effort. The new mechanism could be compatible with the next versions of SonarQube only. Still, it should to handle the case where, in a new version, modules are still present.

      As a nice side effect, the change should also remove a limitation of the current implementation: issues located in shared files (files that not attached to any module) are currently not synchronized.

      HOW

      In VS, SonarLint has to find for every issue whether the issue should be displayed or not. It’s not possible to apply an approach that would compare all local issues with remote ones and from there to find which ones should be hidden. SonarLint has to map each issue independently from the others, and the info about the file is a key to do a correct match.
      This logic has some limitations: For ex, when a same issue is reported several times in a single file and one of these is flagged as won’t fix, all these issues may be hidden in the IDE.

      The current implementation:

      • When the solution is opened in VS, SL finds the guid for each project.
      • With this guid, SL is able to compute the key of the corresponding SonarQube module sonarqube_project_key:sonarqube_project_key:guid.
      • SL periodically requests SonarQube and builds a cache of won't fix/false positive issues per VS project. For each issue, it keeps the file path relative to the project folder.
      • Then, each time an issue is found in VS, SL gets the project and absolute path of the file, and checks if there is a match for the issue in cache.

      Of course, when modules will disappear from the server, SL won't be able to rely on paths relative to projects.

      • Step 1:
        Distinguish the case where SQ project still contains modules from the case where modules have disappeared:
        • If SQ API returns a project hierarchy with several modules: the solution root + modules that correspond to VS projects
          We stick to the existing implementation.
          Note: For the time being, SL gets won't fix/false positive issues per module. It could always requests issues for the whole SQ project.
        • If SQ API returns a project hierarchy with a single level: the VS solution.
          The format of file keys provided by SQ will be project_root_key:relative_file_path_to_root (instead of sonarqube_project_key:sonarqube_project_key:guid:relative_file_path_to_module).
          For each issue, we compare the absolute path of the local file with the path of all the files in SQ and find the best match.

      As an optimization, when we update the cache of issues, we can compare local and remote files and find a pattern (the common prefix) to convert remote paths into local paths.

      • Step 2: Moving to something more similar to what we do in other SonarLint flavors
        When modules exist in SQ, we can get their relative paths. We can then convert paths of SQ files into paths relative to the root folder.
        Then, for each issue, we can always compare the local file path with the path of remote files, even when modules are present on SQ side.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                christophe.levis Christophe Levis
                Reporter:
                christophe.levis Christophe Levis
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: