Enables Branch features:
analyze long-lived branches
analyze short-lived branches
notify external systems when the status of a short-lived branch is impacted
This corresponds to Pull/Merge Requests or 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
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
This is the default. When no specific branch parameters are provided, what is scanned is called the Main Branch. This is what you have in SonarQube when you are not using the Branch Plugin.
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.
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 the 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.
Status vs Quality Gate
The same quality gate that is applied to the project as a whole is automatically applied to long-lived branches as well. This is not editable.
For short-lived branches, there is a kind of hard-coded quality gate focusing only on new issues. Its status is reflected by the green|red signal associated with each short-lived branch:
status: green / OK or red / ERROR
new_bugs > 0
new_vulnerabilities > 0
new_code_smells > 0
Since SonarQube 7.1, it is possible to change the status of a short-lived branch from "red" to "green", i.e. mergable, by manually confirming the issues. The same is true for False-Positive and Won't Fix.
It means the status of a short-lived branch will be red only when there are issues with the status "Open".
Issue Creation and Synchronization
During the first analysis only, issues (type, severity, status, assignee, change log, comments) are synchronized with the Main Branch. In each synchronized issue, a comment is added to the change log of the issue on the long-lived branch: "The issue has been copied from branch 'master' to branch yyy".
Then, at each subsequent analysis of the long-lived branch, any new issue that comes from a short-lived branch automatically inherits the attributes (type, severity, ...) the issue had in the short-lived branch. A comment is added to the change log of the issue on the long-lived branch: "The issue had been copied from branch 'the short-live branch' to branch yyy".
The issues visible on the short-lived branch are the new issues corresponding to files modified in the branch.
Modified files are determined based on the checksum of each file on the sonar.branch.target and the short-lived branch.
Because long-lived branches will persist for a long time, you are likely to develop and release multiple versions from it, and so you can change the Leak Period of a long-lived branch in Administration > Branches.
The ephemeral nature of short-lived branches means no explicit Leak Period is necessary; it's all new code. Thus, no "new code" data is available for a short-lived branch.
Settings and Quality Profiles on Branches
Branch settings and quality profiles default to those set for the master branch, and by design, it's not possible to configure other values.
Only the number of bugs, code smells, vulnerabilities and files are computed. As a consequence, you have no way to get a Quality Gate status as such on short-lived branch.
You cannot connect SonarLint to a short-lived branch.
Analysis of a short-lived branch based on another short-lived branch is not supported.
B y 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.
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: LOCs scanned on long-lived or short-lived branches are NOT counted so you can scan as much as you want without impact on your LOCs consumed