Uploaded image for project: 'SonarQube'
  1. SonarQube
  2. SONAR-9616

Open core to support analysis of long-lived branches



    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.6-M3, 6.6
    • Component/s: Branch & PR
    • Labels:



      • sonar.branch parameter :
        • It must not be stored in metadata.branch field of scanner report anymore.
        • It should only be used to change the project key to <sonar.projectKey>:<sonar.branch>
        • Analysis should fail when specifying a target for the main branch : A target branch doesn't make sense for the main branch. So when the branch specified by sonar.branch.name is the main branch, and sonar.branch.target is present, an error should be raised to avoid any confusion and misuse.
        • The first analysis of a long branch should load project repository from the target branch. Later analysis of an existing long branch should load project repository from its own branch.

      Compute Engine

      • Configuration : Configuration of branches must reusing the configuration of the related project. Except for definition of period leak, a branch can not override the project configuration. Configuration includes:
        • settings
        • association with Quality profiles
        • association with Quality gates
        • webhooks
        • permissions
      • Leak period should be configurable per long-lived branch
      • Notification messages should link to the correct branch
      • Delete the short living branches that are inactive for too long
      • Copy SCM info to branches : When files are unchanged, the scanner sets a flag for the Compute Engine to reuse the SCM info from the last analysis. In the first time a branch is analyzed, the scanner is using the project repository from the target branch, so files that are unchanged compared to the target branch will have that flag set. In the compute engine the reference branch is the last analysis from the branch (none in the case of the first analysis), so SCM info will be missing.

      Web services

      • All web services related to component should fail when the component key relates to a branch component (key contains :BRANCH:name_of_branch) => The caller must use the new parameter branch
      • api/project_branches/list must be created :
        • It returns the branches of the project referenced by the parameter project
        • quality gate (only on long living branch)
        • number of unresolved bugs, vulnerabilities and code smell (only on short living branch)
        • A "isOrphan=true" response is returned if the specified branch does not reference an existing branch (branch has been deleted)
      • api/project_branches/delete must be created :
        • Takes as arguments the project and branch keys
        • Fails if the branch is a main branch
      • api/ce/submit should not accept the parameter projectBranch anymore.
      • api/ce/task, api/ce/component, api/ce/activity should return the following fields on branches :
        • branch : the name of the branch
        • branchType : either LONG or SHORT
      • Add the branch parameter in the following web services :
        • api/ce/component
        • api/components/show
        • api/components/tree
        • api/duplications/show
        • api/issues/search
        • api/measures/component
        • api/measures/component_tree
        • api/measures/search_history
        • api/project_analyses/search
        • api/settings/list_definitions
        • api/settings/reset
        • api/settings/set
        • api/settings/values
        • api/sources/lines
        • api/sources/raw
        • api/tests/covered_files
        • api/tests/list
      • In batch/issues, a new parameter branch should be added :
        • If the branch exists, the issues that are returned are the one from the branch
        • If the branch does not exist, return 404
      • In batch/project, a new parameter branch should be added :
        • If the branch exists, return the files hashed from the branch and the settings from the main project
        • If the branch does not exist, return 404

      Web pages

      • The top-right search engine must not display results on branches. Only the components of "main" project branches must appear.
      • The "Projects" page must be restricted to projects (the main branches).
      • The "Issues" page must not contain issues on branches
      • Branches must not be available in the pages to manage projects :
        • association with Quality profiles
        • association with Quality gates
        • management of projects, including provisioned and ghosts

      Elasticsearch index

      • The following indexes must ignore branches :
        • components
        • projectmeasures


      • Deleting a project must delete all its branches. As a consequence deleting an organization must delete all the branches of its projects too.
      • Changing project visibility (private <-> public) should be applied to all branches. All the branches must have the same visibility
      • Renaming of project/module key must be propagated to branches
      • Ability to manually delete a non-main branch
      • Ability to set the name of the main branch


          Issue Links



              julien.lancelot Julien Lancelot
              simon.brandhof Simon Brandhof (Inactive)
              1 Vote for this issue
              5 Start watching this issue