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???
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
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
The result in sonarqube 8.5 looks like this. The develop branch is created parallel to the master.
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.
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.
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??
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
I just want to make sure I understand… Right now I have projects that have renamed their github default branches from master → main. So in SonarQube I still see master as the main branch, and there is also a separate main branch.
Is the right process to remedy this to, from SonarQube, to delete the main branch, and then to just rename master → main?
What happens with the next scan that takes place on main? I assume then it would take all the changes since the default branch was renames and treat that as new code?
It depends of which of the options you chose to define the new code on your mainbranch, but sometimes yes.
If new code is defined as previous version, yes. If you want to work around this side effect, you could analyze the main branch based on a tag that corresponds to the previous version (to set the baseline of the new code first), and then analyze the head of the branch (to set the new code)
If new code is defined as number of days, no. This is solely based on commit dates
If new code is based on reference branch, no. The diff between the reference branch and current branch
If new code is based on specific analysis, yes. Just the for previous version, if you want to workaround this side effect, you could analyze the main branch based on a commit that corresponds to the specific analysis that should mark the beginning of the new code and (to set the baseline of the new code first), and then analyze the head of the branch (to set the new code)
Suddenly today the related Jira issue MMF-1335 has been deleted by Christophe Lewis, @OlivierK do you have any idea if that has been integrated into current 9.x release?
Hello @warden,
Although it’s relatively long term, it’s now planned, not for a random 9.x, but specifically 9.5, and the single source of truth to follow is our public roadmap portal
Olivier
Hi @warden,
I invite you to subscribe to future updates on our roadmap page.
MMF deletion was not intentional and we’ll try to restore it to inform watchers from this move.
Is there any way to do this without deleting the old branch? We’ve been analyzing under mainline for many months and would like to make it the default instead of master, but we don’t want to lose all of our analysis history.
Ideally, I’d like the option to just set mainline as the main branch.
Is there any way to do this without deleting the old branch? We’ve been analyzing under mainline for many months and would like to make it the default instead of master , but we don’t want to lose all of our analysis history.
Ideally, I’d like the option to just set mainline as the main branch.
