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

Hi,

using Sonarqube Enterprise since version 5.x
With the upcoming of the branching feature we switched from using the LTS version to the most
recent version to be able to use branches - we used multiple Sonarqube projects
for different branches before.
All works fine, after the users had get used to the concepts of short-lived and
long-lived branches.

I very much welcome the decision to go from short-lived/long-lived branches to a branch is a branch,
but the implementation has a serious defect.

It simply doesn’t work with Quality gates that have new conditions, as the definition of new
is impracticable.

See all the details in this thread

I’m quite disappointed that this shortcoming has not been taken into account :frowning:
The proposed workaround - means using pull requests instead - is a hack, but no solution.
You have to set sonar.pullrequest.key and sonar.pullrequest.branch,
(sonar.pullrequest.base is default = master).
Using a dummy pullrequest key leads to

Also users won’t accept this, they are used to branch analysis works fine with
simply using sonar.branch.name - why do i have to fake a PR ?

Please bring back sonar.branch.target with default = master to make it work again.

Gilbert

Yeah, couldn’t agree more. My company is very large Enterprise level, and our codebase alone for my division comprises a total of 750 components, 8million+ LOC, with multiple maintenance releases continuously being updated, due to customer requirements. So, essentially, SonarQube has decided to say FU to all of our incredibly large, global customers, ensuring that they have static analysis performed on their software? SonarQube, this was shortsighted, and makes zero sense from a maintenance release perspective. We’re talking about maintaining forked software here, which essentially may as well be a completely different codebase. It also makes zero sense from a software release perspective for you guys. I mean, as an Sr. Software Engineer and Architect I find it ridiculous that you can’t maintain something as simple as that. Additionally, considering a proposal to go back to coverity over this, as we deal with PCI compliance issues, which is now requiring static analysis on maintenance releases, something you no longer support. I loved you guys at first, now I’m feeling stung by your hubris.

John,

SonarQube still supports Branch Analysis, and I can’t draw a line between the topic of this thread (definition of New Code on branches) and what you’re talking about (analysing maintenance branches).

Colin

@Colin_SonarSource - I’m not sure what you mean by “draw a line”. Do you mean you are unaware of how some dev orgs utilize maintenance release versions, and maintenance branches for applying bugfixes and enhancements to them? Sorry, maybe we’re talking past each other here. We do utilize a standard git flow model (with some customization). However, this is a pretty common branching model that’s been around for a while now. As stated, we have multiple releases in the field that require support up to n number of years, with some customers unwilling to upgrade. This creates a situation where any new enhancements, features, or even minimal refactors, have caused us to fork. Without the ability to generate a delta between a given branch and the integration branch it is being merged into, we’re missing one of the most important features of static analysis. That is, finding new issues/bugs/etc compared to what is in the version we are merging the code into. Does that clear it up?

1 Like

Basically, without the sonar.branch.target we are now unable to generate this delta on “historic” (for lack of a better term) bugfix branches.

Thanks John. “draw a line” was another way of saying “connect the dots”.

You might be interested in MMF-1994 - Allow visualizing new code since the branch was created

@Colin_SonarSource - Hey man, I totally get it. This makes sense, and seems like a simplistic manner in which to both present your product, and also keep the focus on where the “real” change happens to code. However, as one of the worlds largest payment processors, we have to maintain PCI compliance on all of our software. This means that even if we have software out in the field which is 4 years old, and a customer pays for an update but doesn’t want all of our new features, then we’re forced to supply it. But without the ability to perform meaningful static analysis on this code, we run the risk of being non-compliant, and therefore risk fault. In previous work places, I would be trumpeting your cause; however, that isn’t the case anymore.

@Colin_SonarSource - Basically what I’m saying is that sometimes, “new code” is also introduced on maintenance versions. And yes, this does cause quite the headache in technical debt. However, I did read the user story on the ticket you referred me to, and can agree that in a CI/CD model (which we also employ), it’s the best. But again, we just need a way in which we can provide static analysis on maintenance release enhancements. Hmmm, thinking about the statement of “SonarQube is analyzing branches, the same way branches are defined in the SCM, with the whole code and not comparing it to another branch.” This is, in fact, our breaking point. Reasoning is thus: All mainenance branches in a gitflow model can be considered forked software, and therefore may no longer have the same functionality, class definitions, methods, etc of what exists at HEAD of the current release branch. Though, most will be the same, and should inherently be backwards compatible. This isn’t always the case in such instances as a refactored component, etc.

1 Like

We only just recently updated to SonarQube 8.7.1 from the former LTS 7.9 only to discover this “feature” is breaking our development model. The discussion is now a year old (and JIRA is unavailable at the time of my writing) so I’d like to ask what exactly is the progress with this discussion?

Just to clarify the sonar.target.branch might not have been perfect but it gave a newly pushed branch a baseline of code and issues to begin with.

In our projects we analyse every feature branch to provide immediate feedback if something is wrong and only a minority of them is then merged via pull requests. While this might not be the academic approach - it is what it is. Until 7.x the developers could rely on the branch build+analysis to make sure their code is most likely compliant with the QGate when merged to the development branch.

If I understood the discussion correctly we are now forced to push a empty branch first. Wait for the first analysis to finish and then push the actual changes to achieve the same goal as before, right?
This feels like going back to the old days of Sonar 4.x where branches where separate projects and we had to do a manual analysis to get a baseline.

And this is not only a convenience issue, to get a baseline one has to run such a analysis physically that is time no one is keen of waiting for.

I’d like to know if there is any progress to address this issue. As of now the Sonar Analysis seems broken for feature branches that are initially pushed with already implemented changes - with is most likely the default for us.

1 Like