Sonarqube 8.1 branch analysis, bring back sonar.branch.target

When Sonar Team going to add sonar.branch.target property back?

2 Likes

the sooner the better :grinning:
But seriously, with a lot of votes for this feature request and a LOT of related postings this problem has gained enough attention from Sonarsource - see @Chris posting above.
I hope / wish there’s already a solution in the making.

Gilbert

2 Likes

Any idea when this issue will be resolved.

i’m no Sonarsourcer and have no glance when this will be implemented.

Hi all,

These will ship in 9.4 (E.T.A. 4 April):

  • SONAR-16162 Enable New Code based on “reference branch” with a scanner parameter
  • SONAR-16163 Process reference branch set by the scanner in the CE
  • SONAR-16164 Document new scanner parameter ‘sonar.newCode.referenceBranch’

 
:slight_smile:
Ann

4 Likes

Hi Ann,

great news :partying_face:

though much more to write :wink:
sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23

From the descriptions in Jira it seems to be not different from old sonar.branch.target
behaviour beside the name.

Gilbert

1 Like

Thx, great news indeed!

sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23

what does this mean?

g,
Peter

He’s just saying it’s more typing to get the same effect. :slight_smile:

Just consider the new, longer name a sop to our pride. :wink:

 
Ann

1 Like

sonar.newCode.referenceBranch = length 33
sonar.branch.target = length 23

^^^ There is zero equivalence, according to Sonar documentation, for these two properties. Why would you misconstrue, and conflate this? Again, deprecating sonar.branch.target is the most inane, and unconsidered approach SonarQube could do for VERY large enterprise organizations, whom have created implementations based on their delivery model, and SonarQube’s properties. I will be advocating for another solution now. Even though I loved SonarQube over our bespoke, and costly implementation of Coverity, this deprecation of a very basic feature could potentially cost our organization millions. I’m still unsure why Sonar has removed such a simple way to generate a delta based on a branch to be integrated to. I’ve explained enough in my previous comments on this thread as to why this feature change will hurt us. So, we’re kind of stuck.

How is that a solution? It is not the same. Please elaborate on implementation? We just upgraded to 8.9.6, and are now facing serious consequences.

This is a singular case example. which may work in your implementation, however, I can pretty much guarantee that many organizations will not have this type of integration. Previously, sonar.branch.target was simple to implement, and ensured that new code was analyzed against a delta of the specified target branch in question, rather than a more generalized, and defined common base target branch (e.g. “master”). This implementation fails when it comes to maintenance releases.

Hi John,

We’ve recently added the possibility to set a reference branch depending on the branch you are working on.
The parameter is not the same because the management of branches changed since the time we had short-lived branches. Since SonarQube 8.1, the concept for branches was simplified: short-lived and long-lived branches are just branches. Also, choosing a branch as a reference is considered a way to define the New Code on your working branch.
Can you please explain your use case if this still does not answer your need?

Chris

Here is my case: We are a very large enterprise organization currently using SonarQube version 8.9.6 (recently upgraded from 7.9). I noticed that a critical aspect of our implementation was now missing, the sonar.branch.target property, after the upgrade. We have a monolithic codebase consisting of over 850 components/modules (550 are Java, 300+ are native), each one receiving their own project in SonarQube. We do have an integrated tool chain; however, our Sonar is integrated into our build architecture, and implemented via a custom ant solution (I’ll avoid all the details here, though). Since our organization is contracted to support maintenance releases for many major enterprise customers, we also need the ability to control how a given branch’s delta is derived against its relative integration branch (there is only one), or release branch (many). Because of this, we need a method to automate the setting of a newly defined reference branch at compile time, for each module/sonar project, we analyze. After doing more research, I was able to find that using the sonar.newCode.referenceBranch does seem to provide the necessary feature we need, by setting this property each time we would be able to compile a component in our code base (again, I’m not going into to much detail as I am refactoring this incredibly complex build architecture soon) and set the new code period for the “long lived” branch specified now as the reference branch; however, that property isn’t actually available unless we upgrade to at least version 9.4 (per documentation). Unfortunately, I don’t manage the upgrades, but I do have some sway in the solution our company goes with, because our internal org represents the largest profit generator there. Hope that helps you understand our case. In terms of the management of branches, after version 8.1, it seems that SonarQube made many assumptions of how very large organizations manage software releases, and maintenance; which I find to be wrong, in several enterprise cases. Unless, of course, a dev org only needs to be concerned with the newest release, always. In our case, we may have a release branch which currently can live on in perpetuity, thereby breaking this assumption.

2 Likes

By the way, we also have a group that creates a custom OS, which also follows a similar model, yet it is multi-repo based. When using Sonar 7.9, we also implemented the sonar.branch.target property for this group, as well.

Oh yes, one more thing. I should at least mention that when we moved from Coverity to SonarQube, I was one of the biggest proponents internally driving that. I love what SonarQube provided us at that time, relatively speaking.

Thanks for sharing John.
We try to make SonarQube friendly with the way of working in large organizations. I can understand your need and unfortunately, this new code definition is a major change that was added after the 8.9 LTS. Happy to read that the new configuration will meet your expectations.

It does, we just have to upgrade to the 9.4 version to get it, unfortunately. Do you happen to know if there is a maintenance release off of 8.X.X with this new feature?

Hi,

There’s not. The LTS isn’t updated for new features. Only significant bugs and vulnerabilities.

 
Ann

Hi,

we use Sonarqube Enterprise edition.
I’ve decided to go with the latest Sonarqube version in 2017 to be able to use the latest / new features.
Beside some problems with early 8.x versions we never faced any problems.
As now it ain’t possible to update language scanner plugins - i.e. Sonar Java - without updating your Sonarqube instance, it’s IMO mandatory to go with the latest Sonarqube version if you need to support the latest i.e. typescript/javascript … syntax.
As Enterprise customer since 2016 i recommend to go with the latest version instead of LTS (every 18 month) to use the most recent language scanner plugins.

Gilbert

3 Likes

A post was split to a new topic: Java 8 support in SonarQube versions after 9.X?