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

SonarQube Product Manager for a Day
1

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

sq_pr
sq_pr1135×357 15.2 KB

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

4

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.

5

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

6

@Colin - 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?

2 Likes
7

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

1 Like
8

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

9

@Colin - 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.

10

@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
12

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.

5 Likes
13

We have recently upgraded to latest sonar version and its doesnt make sense of new code scan analysis as developer run scan on every branch they create and once they forgot then first scan wont highlight any issue and its basically baseline scan. Earlier option of target branch was really useful for tracking new code changes. Its better to have some scan parameter option to set reference branch which is the new feature introduced in the latest Sonar.

2 Likes
15

If I understand this correctly, it makes the branch analysis feature useless?? We got the developer edition for this feature alone.

16

Not useless but waaaaaaay more clumsy / inconvenient :frowning:
You may use the Sonarqube web api like that

As the former way to do that via property sonar.branch.target has vanished with Sonarqube 8 it’s only possible to set this with the web api or via web ui, the default new code setting for a branch is previous version

Otherwise when using PR analysis which is activated with properties
sonar.pullrequest.key, sonar.pullrequest.branch, sonar.pullrequest.base
the new code is defined by branch and base.
see Pull Request Analysis | SonarQube Docs

Still hoping sonar.branch.target comes back.
In the meantime my feature request has already 13 votes.
So i guess there’s a serious requirement of the community as this topic comes up again and again.

2 Likes
20

Hey,

i am struggeling also with the “NEW CODE”. I try to set the reference branches over the API.

For branches that are present, it works. We use Multibranch Pipeline in Jenkins and I want to create new branches manually in SQ before the actual SQ analysis, so that the reference branch is set at the first analysis.

How can I create a branch manually in SQ?

thanks

21

Hi Mark,

no need to create a branch manually. We also use a generic Jenkins mulitbranch pipeline
with the steps 1. - 5. described in the posting i quoted above = “Sonarqube 8.4.1 branch analysis, definition of new ?!” and it works fine - also for new branches.
Of course this works only as general setting for all branches using the main branch as reference branch.

Gilbert

22

Hi Gilbert,

I am not sure how to adapt your steps 1-5.

below you can see my settings, set at the beginning.
feature/* → project setting(reference develop)
develop → reference branch “master”
master → previous version

my question is, how can I handle bugfix/* or release/* branches?
ok, at the beginning they are set to “project settings” automatically, but I want them to be on reference - > master.
I don’t want to do it manually every time.

thanks

reference
reference1399×778 37.9 KB

23

Hi Mark,

as this web api call needs an existing branch $BRANCH_NAME
/api/new_code_periods/set?project=$projectKey&branch=$BRANCH_NAME&type=REFERENCE_BRANCH&value=master

and sonar.branch.target property ain’t available anymore, you may use a pull request,
when in your case sonar.pullrequest.branch would be the bugfix/* or release/* branch
and master sonar.pullrequest.base

24

Hi Gilbert,

sorry, I can’t follow you and now I’m totally confused.

Maybe I am missing some important information. PR is already a step further, I am concerned about the actual source branch. Even if I work with PR, the source branch (sonar.pullrequest.branch=feature/* or release/*) must already exist in Sonarqube.

My plan was to place an API call in the Jenkinsfile right after checkout, which is started before the actual sonar analysis, so that the first time “feature/*” is analyzed, the correct reference is also set immediately.

We are using the Bitbucket plugin in Jenkins so we don’t need the PR properties.

Can you please write me your complete flow.

Would also be nice if someone from Sonarsource could comment on this.

I saw that you work/live in Germany. Maybe we can talk/write privately

25

Not sure if this will help, but I just upgraded from sonar 7.9 to 8.9 and am now using the PR functionality with Bitbucket and Jenkins. I use the sonar scanner with the sonar-project.properties file, which gets built by my build script during build execution. You can also use define these same parameters as command line parameters for sonar scanner. This is what my settings look like for a given build and the analysis for new code works as expected.

sonar.host.url=https://sonar.xxx.com
sonar.projectKey=plugin-fundus
sonar.sources=/tmp/jenkins_workspace/plugin-fundus/workspace
sonar.tests=/tmp/jenkins_workspace/plugin-fundus/workspace
sonar.test.inclusions=**/*_test.go,**/testdata/**
sonar.pullrequest.key=2
sonar.pullrequest.base=master
sonar.pullrequest.branch=feature/ENG-1258
27

@CameronG Above properties has nothing to do with new code analysis. New code analysis configuration is being set in the Sonar portal and it latest version we cant set it via property which was possible earlier and it was convenient options. With latest sonarqube now you need to go and login in UI to change to target branch every time. Earlier property which was there sonar.branch.target its removed by Sonar team and made SonarQube new code analysis whole lot of complicated for typical enterprise project having multiple source code repositories/sonar projects.

28

Hi,

With the introduction of the reference branch to better track new code in features/bug-fix branches, it seems the configuration is still not as flexible as you would expect.
If my understanding is correct, you need a way to set the reference branch depending on the branch you are working on, without waiting for the branch to be created and without going into the UI.
That’s an important feedback that we are tracking and that we are considering with an effort to simplify automation of project and branches creation.

To better understand your context, do you use a same pipeline configuration that applies to all branches and PRs of your project? And, when it’s the case, how do you generally set the configuration which is specific to the project?

Chris

2 Likes