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

Minimal support for Long-Lived Branches Analysis in SonarQube

    XMLWordPrintable

    Details

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

      Description

      MMF-969 is considered as being a pre-requisite before implementing this support for long-lived branches.

      The Problem

      A long-lived branch is a branch whose distance to the main branch can be really important in term of number of changes and on which a dedicated development lifecycle is often put in place. Maintenance branches are probably the most popular type of long-lived branches. Obviously the leak metaphor paradigm is perfectly suitable for long-lived branches and all SonarQube users want to track the quality on those branches. For the time-being there is only one way to track code quality on long-lived branches :

      • "Duplicating" a project in SonarQube with help of the "sonar.branch" property

      But this approach has the following drawbacks:

      • 1- The search engine can quickly become unusable if too many long-lived branches are analyzed
      • 2- Lot of issues and measures are duplicated between the long-lived branches and this can pollute the global Projects and Issues pages.
      • 3- FP and "Won't Fix" issues are "reopened" when analyzing long-lived branches

      The Idea

      Long-lived branches should be accessible and searchable only inside a project (see MMF-969) instead of duplicating projects as it is currently done (this should solve limitation 1). Moreover issues and measures of a long-lived branch should not be accessible outside of this long-lived branch (No access from the global Projects or Issues page to fix limitation 2).

      Even if conceptually there is a difference between a long-lived branch and a short-lived one, in SCM engines all those branches are managed the same way, so how to make the difference between a short-lived and a long-lived branch ? Simply by relying on a regular expression provided with help of a new settings parameter like sonar.branch.longLivedBranches.regex=branch-.*.

      In case of long-lived branches, the head of the main branch will go too far from the head of the long-lived branch to make the issue tracking working well in the long run. So the issue tracking mechanism can't rely on the head of the master. Nevertheless, for the first analysis of a long-lived branch we expect all the non-closed issues of the main project to be duplicated in order to reuse "'at best" the issue review effort done on the master (FP, Won't Fix, comments, ...). This initiale duplication of issues will solve limitation 3. This overall strategy will make the analysis of long-lived branches being by definition more costly in term of resource consumption compared to the short-lived branches:

      • Full analysis
      • All filles
      • All issues
      • All measures

      A long-lived branch should inherit from the settings and permissions of the main branch without having the ability to override them. Moreover, the activity page must be blank at first, we don't want to inherit from events of the project. The only thing that must be configurable in a long-lived branch is the leak period.

      Finally when analyzing a branch which was already analyzed before with help of the sonar.branch.name parameter, this should lead to automatically convert this 'project' into a long-lived branch.

      Out of scope

      • Keeping a link between matching issues in the long-lived and main branch to keep comments/resolution/assignee in sync.

      The Solution

      No difference between the analysis of a long-lived branch and the analysis of a short-lived branch: we just have to use the analysis property sonar.branch.name. And based on the value of sonar.branch.longLivedBranches.regex we decide if the branch is a long-lived or short-lived one.

      When clicking on a long-lived branch, we expect the breadcrumb to make it clear that part of a project we're browsing a dedicated long-lived branch. And for this long-lived branch we do expect to retrieve all the pages available at project level : Home, Issues, Measures, Code and Activity (TODO: extract the configuration of the leak period outside of the Settings page). Deletion of a long-lived branch should be manual. Obviously the deletion of a project should lead to delete all its short-lived and long-lived branches to prevent generating any orphans.

      By supporting long-lived branches this raises the question of the selection of the referential long-lived branch when analyzing a short-lived branch or another long-lived branch. This must be done with help of the sonar.branch.target analysis property. If this referential branch doesn't exist the main branch must be used. There are two ways to define the main branch :

      • Either by pushing a first analysis on a project without specifying a value for sonar.branch.name. And in that case, the name of the default branch should become [main branch]
      • Or by specifying a value for sonar.branch.name even if this value doesn't match sonar.branch.longLivedBranches.regex.

      Once the main branch has been defined there is no other way to change it than deleting the project.

      Moreover, in the "Background Tasks" pages, we do expect to retrieve for each row relating to the computation of a long-lived branch analysis report :

      • The name of the project
      • The icon of long-lived branches
      • The name of the long-lived branch

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              fabrice.bellingard Fabrice Bellingard
              Reporter:
              freddy.mallet Freddy Mallet (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: