Branch analysis is available as part of Developer Edition and more.
Branch analysis allows you to:
analyze long-lived branches
analyze short-lived branches
notify external systems when the status of a short-lived branch is impacted
This corresponds to Maintenance Branches that will house several release versions. This kind of branch will:
last for a long time
inevitably diverge more and more from the other branches
house several release versions, each of which must pass the quality gate to go to production not be expected to be merged into another branch
For more, see Long-lived Branches.
This corresponds to Feature Branches. This kind of branch:
will disappear quickly
will be merged rapidly to prevent integration issues
is developed for a given version, so the version does not change, and there is no Leak Period concept as such; it's all leak period tracks all the new issues related to the code that changed on it.
For more, see Short-lived Branches.
Master / Main Branch
This is the default, and typically corresponds to what's being developed for your next release. This is usually known within a development team as "master" or "head", and is what is analyzed when no specific branch parameters are provided. It is labeled "Main Branch" and defaults to the name "master", but can be renamed from within the interface. When you are not using Developer Edition, this is the only branch you see.
A branch is created when the sonar.branch.name parameter is passed during analysis.
Name of the branch (visible in the UI)
Name of the branch where you intend to merge your short-lived branch at the end of its life. If left blank, this defaults to the master branch. It can also be used while initializing a long-lived branch to sync the issues from a branch other than the Main Branch.
By default, TravisCI only fetches the last 50 git commits. You must use git fetch --unshallow to get the full history. If you don't, new issues may not be assigned to the correct developer.
Configuring the Branch type
A regular expression is used to determine whether a branch is treated as long-lived or short-lived. By default, branches that have names starting with either "branch" or "release" will be treated as long-lived.
This can be updated globally in Configuration > General > Detection of long-lived branches or at project's level in Admininstration > Branches.
Once a branch type has been set, it cannot be changed. Explicitly, you cannot transform a long-lived to short-lived branch, or vice-versa.
Q: How long are branches retained?
A: Long-lived branches are retained until you delete them manually (Administration > Branches). Short-lived branches are deleted automatically after 30 days with no analysis. This can be updated in Configuration > General > Number of days before purging inactive short living branches.
Q: Do I need to have my project stored in an SCM such as Git or SVN to use this feature?
A: No, you don't need to be connected to a SCM. But if you use Git or SVN we can better track the new files on short-lived branches and so better report new issues on the files that really changed during the life of the short-lived branch.
Q: If I flag an Issue as "Won't Fix" or "False-Positive", will it be replicated as such when merging my short-lived branch into the Master?
A: Yes. Each time there is an analysis of a long-lived branch, we look at the issues on the short-lived branches and try to synchronize them with the newly raised issues on the long-lived branch. In case you made some changes on the issues (false-positive, won't fix), these changes will be reported on the long-lived branch.
Q: Can I still use sonar.branch?
A: The parameter sonar.branch is deprecated. You can still use it but it will behave the same way it always has: a separate project will be created. We encourage you to smoothly migrate your users to the new parameter sonar.branch.name.
Please note you cannot use sonar.branch together with sonar.branch.name.
Q: Can I manually delete a branch?
A: This can be achieved by going into the Administration menu at Project's level, then Branches.
Q: How do I control the lifespan of a short-lived branch?
A: As a global admin, you can set the parameter sonar.dbcleaner.daysBeforeDeletingInactiveShortLivingBranches to control how many days you want to keep an inactive short-lived branch.
Q: Does the payload of the Webhook contain extra information related to Branches?
A: Yes, an extra node called "branch" is added to the payload. See MMF-988 - Manual changes on issues of short-lived branches must trigger the webhook call Closed for more details.
Q: When are Webhooks called?
A: When the computation of the background task is done for a given branch but also when an issue is updated on a short-lived branch.
Q: What is the impact on my LOCs consumption vs my license?
A: The LOC of your largest branch are counted toward your license limit. All other branches are ignored.