How to change the main branch in SonarQube?

Hello @ARUN_GUPTA,
This is SonarCloud and your problem is relatively different from the original problem in that thread. Can you open a new thread please? Thanks

Hi @all,

I have also a question/problem about the Main Branch in the Sonarqube 8.5.

We are currently in the process of updating our Sonarqube (developer Edition) from version 7.9.1 to 8.5.

But before we update our live instance, I would like to test the new features on the test instance.

So, our test instance (developer edition) is now on version 8.5 and I have a question about the process of creating a new project.

Analyzing a new project (first develop) in Sonarqube 7.9.1 means analyzing with the missing parameter “sonar.branch.name”.
The main branch, marked as “master”, has been created but could be renamed to “develop”

On the Sonarqube 8.5 I see two branches -> develop and master. Master branch was created automatically without analysis.

No matter what I do on Sonarqube 8.5, my develop branch is always created parallel to the “master” branch (main branch).

In develop is the result of the analysis and the master is empty, but with the error message “master Branch has not been analyzed yet and you have multiple branches already. It looks like it is not your Main Branch, check your configuration.”

If I want to rename the master branch, like in Sonarqube 7.9.1, it tells me develop already exists.

What is the procedure to create a new project in Sonarqube 8.5 and the develop branch should be my main branch???

thanks
Mark

Hello @markluebbehuesen,

The behaviour on SonarQube 8.5 is the same as on 7.9. The only difference with 8.5 is that it is now allow to analyze a “non main” branch before the main branch (which was not possible in 7.9), and I think that what caught you in a trap. My guess from what you describe is that you analyzed the develop branch first and you passed sonar.branch.name=develop which caused to create a non main branch before the main one (which was not possible in 7.9).

The best way to fix the problem is to delete the project and start again analyzing the 7.9 way:
– Not passing any sonar.branch.name parameter when analyzing develop (this will create a branch initially called master that you can rename as develop)
– Analyzing master by passing the parameter sonar.branch.name=master

Olivier

Hi @OlivierK,

thanks for the answer, but unfortunately it doesn’t work the way you describe it.
It is correct that the master(main branch) is also created this way in sonarqube7.9, but it doesn´t work here.
I don´t use the parameter “sonar.branch.name”, see the following picture.

Sonar plugin in Jenkins -> sonar-scanner-4.5

scanner

The result in sonarqube 8.5 looks like this. The develop branch is created parallel to the master.

Do you have another idea or where is the mistake? I have done so many projects this way in SQ 7.9 without any problems.

thanks,
Mark

Hello @markluebbehuesen,

I do have a good idea from what’s happening but it’s deviating quite a lot from the original topic of the thread.

I’ll ask you to open a new one to discuss your case (and provide all the context of the last post)

Olivier

PS/ I suspect that the behaviour change is due to a combination of changes in SonarQube and the Scanner for Jenkins and the fact that you apparently use a Jenkins multibranch pipeline.

Based on script by @Opa, here is an updated version of the script and related ticket MMF-1335.

The Prepare Analysis task appears to break when you run a cross-project pipeline.
At least, in our case I followed this logic, and the prepare task fails to determine the ‘default’ devops branch when I run the pipeline from one DevOps project and target a repo from another project.
Looking in github it appears the task is using a System.TeamProject value (to get the repo) that I suspect is gathered from the ‘current Project’ instead of the project that the repo actually lives in.

Hi @OlivierK ,

Thanks for your comments on this , As you said you can analyze develop branch or release branch as master without using sonar.branch.* parameters which is pretty good .

Actually we have a requirement here basically the similar one , so As of now we will be using Sonarqube enterprise version soon and will be analyzing lot of repos including different branches and pull requests which we have already done POC and working as expected.

In the same way we have monitoring tool that we will be using as Datadaog where we have integrated Sonarqube with datadog to get metrics of sonarqube dashboard into Datadog which is also working as expected during our POC, But one limitation with getting metrics from sonarqube into datadog is that We can only get metrics related to master(main Branch) and we cant get metrics related to any other branches .

So One work around we are looking here is we wanted to change the current release branch to master (main Branch) in Sonarqube so that every release we will be updating that and we will be getting the metrics subsequently to Datadaog.

Hope you understood my requirement? Can you please let me whether do i need to flow the above process so that our release branch will be a default branch in Sonarqube so that I can metrics into Datadaog ?

is there any other alternative approach regarding this to implement??

Hello @vinodkumar4b9,

Please open another discussion thread if you need more follow up on this since what you’re asking about is a completely different topic.
But the quick answer is NO you don’t need to do any workaround. Each of the API you successfully used to extract metrics (actually measures) into datadog should have a branch parameter that lets you extract data from a specific branch instead of the main branch (which is the default if branch is not specified).
Example:

# Returns ncloc, bugs and vulnerabilitites for main branch of project <projectKey>
api/measures/component?component=<projectkey>&metricKeys=ncloc,bugs,vulnerabilities

# Returns ncloc, bugs and vulnerabilitites for branch release-2.1 of project <projectKey>
api/measures/component?component=<projectkey>&metricKeys=ncloc,bugs,vulnerabilities&branch=release-2.1

Olivier

Hi,

As you said, I will open an another thread .

Thanks for the details