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

Closed issues in short living branches should be merged into the target branch


    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: None


      The situation

      Support for short living branches has been added to SonarQube. This empowers users to deal with issues raised on their short living branches right from SonarQube's UI and do all the same actions on them as they can on a regular branch.

      Currently, however, when the short-living branch's code is merged into the target branch's code, all this work is lost. All issues raised on the short living branch will be raised as new issues on the target branch.
      In particular, any issue which may have been closed as "won't fix" or "FP" on the short living branch, any comment added on them, won't be visible on the target branch.

      This implies that any work done on the short living branch is lost when the branch is merged, which implies that the developer has no reason to do anything on short living branche's issues as anything they do will have to be done again on the target branch.

      The solution

      To solve this, the idea is the following:

      After all regular issue tracking on a target branch has been done, an extra step is added that will, for each file:

      1. if there is any open issue on the file
      2. retrieves all non-open and non-closed issues on the same file (trouble there is currently no easy not performant way of matching a file across branches) on any short living branches which have the current branch as a target
      3. TO BE DEFINED match open issues of the file with retrieved issues above
        • Option 1: reuse issue tracking algorithm
          • does not support multiple issues from the base matching an open issue
          • quite lenient, could generate FPs
        • Option 2: do a simpler, yet stricter, issue tracking on the open issues of the file against the issues retrieved from short living branches:
          • same rule, same line number with same line hash
          • if issue is new (ie. creating during the current analysis), just merge it with the issue from the short living branch
          • if issue is not new (ie. created before the current analysis), apply transitions (which will therefor include notifications) to be merged into the short living branch issue


      • only issues specific to the short living branch as supposed to exist in the short living branch.
        • therefor, there is very low risk of altering issues on the target branch before the short living branch is really merged
      • only the fixed but not closed issues from the short living branch are considered
        • because closed issues are supposed to be either not raised at all on the target branch (the code has been fixed) or closed automatically (for the same reason)
      • issue tracking is stricter and won't work if the code is not exactly the same
        • because the code is supposed to be merged into the target branch, resulting into the code of the target branch to be exactly the same as of the short living branch

      potential performances impacts

      With the algorithm described above, during the analysis of a long lived branch, all short living branches targeting that long lived branch will be taken into account. Since short living branch can currently leave on in SonarQube for a long time before being deleted (default is 100 days without analysis, IIRC), that could lead to retrieving many issues from many short living branches for a long time.


          Issue Links



              • Assignee:
                freddy.mallet Freddy Mallet (Inactive)
                sebastien.lesaint Sebastien Lesaint
              • Votes:
                0 Vote for this issue
                3 Start watching this issue


                • Created: