GitLab vs Sonarqube Default Branch

Versions :
SonarQube community deployed with helm chart on AKS : sonarqube-10.0.0+521 | 10.0.0
GitLab SaaS (
Scanner: N/A

How to reproduce the issue :

  1. On a fresh install of sonarqube perform GitLab ALM integration : GitLab integration
  2. On create a new empty repo with 2 branches (main and develop)
  3. Change the default branch to develop
  4. Add the project to Sonarqube via GitLab integration already configured
  5. The default branch name that appears on the configuration page (How do you want to analyze your repository?) is develop :white_check_mark:
  6. Remove the project from Sonarqube
  7. In GitLab switch the default branch back to main
  8. Add the project again into Sonar
  9. The default branch name that appears is still develop :x:

Bonus: On a legacy project that was still using master branch I also have a default branch in Sonar to main while main does not even exit in the repo.

My understanding is that for some reason Sonar fail back to sonar.projectCreation.mainBranchName.

But it should not since :

Hi @Autofocus!

Thank you for raising this.

Indeed, the sonar.projectCreation.mainBranchName is taking priority over the Gitlab project’s configuration.
I tried with other ALMs, but only Gitlab looks concerned by this bug.

I have opened a ticket here.


We have spent some time investigating and we think we finally catch the root cause of the issue: Sonarqube is not managing GitLab pagination when retrieving the branches list from GitLab.

Source : public List getBranches(String gitlabUrl, String pat, Long gitlabProjectId) {

The default gitlab number of results is 20 meaning on big repo that contains more than 20 branches the default branch may not appear (what’s the reason why Sonarqube failbacks to default sonarqube branch name).

Reference GitLab doc : REST API | GitLab

Thank you so much for sharing this investigation; It will certainly be helpful!

I wonder if pagination is the only explanation; I tried with a small repository with only a few branches. Still reproduced the issue.

Hello @Autofocus

I’m another Antoine from Sonar :wink:
While investigating the issue, we realized that:

  • there is a bug in the GitLab API: when the default branch is changed, it’s not immediately reported in the API endpoint SQ uses. So we basically can’t detect the default branch.
  • after some time (a couple of hours, we checked after 11 hours in our case), the endpoint do report the correct default branch. If I try to provision the project at that moment, it works well and SQ is able to setup the right default branch

So all in all, it looks that a change in the default branch takes time to be reported in the GitLab API. We opened a ticket with them and will further investigate this.

Meanwhile, could you try to provision a project where the default branch is settled since a while? ie. not a new project or not one where the default branch recently changed (less than a day).
If it’s still doesn’t work, could you copy/paste here the result of the GitLab endpoint

Sonarqube is not managing GitLab pagination when retrieving the branches list from GitLab.

That appears to be true as well, however it’s not unlikely that the default branch is the first one listed by this endpoint, so looking at other pages is not needed. I’m not sure about that, I first would like to eliminate the GitLab bug which doesn’t immediately report the right default branch, then look into this.


Hello Antoine and thanks for the investigation,

As you can see we are talking about two differents issues:

  • The time it takes for SonarQube to see a change of GitLab Default branch (that is actually just a side effect of me trying to produce a minimal reproducible scenario). On my side it did not take that much time (11h) to reflect (less than 1h for sure).
  • The pagination which was the real issue we was facing in a real entreprise gitlab project.

For the first one I noticed that the default branch reflect immediately on the UI of GitLab which means there are doing it differently. After investigation it seems that there are using the graph API instead the REST.

For the second one, I think it will be really common for a lot of customers since the default order is sorted by name alphabetically and by default all feature branch in GitLab start with a number. That’s the reason why in our project the default branch will never show up in SonarQube :

From my perspective since the graphQL endpoint is exposing the default branch directly (contrairly to the REST API) it could be a good alternative to fix both at once :

I join a minimal example. New GitLab public repo created with one Issue and 20 related branches : does not display any main or default branch.

You’re right, we can see that:

  • doesn’t show the default branch
  • but does show it (it’s main)

So let’s ignore the temporary problem of Gitlab not flagging the default branch, which anyway won’t be solved in SonarQube. However, we will fix the pagination issue in SONAR-19529.

Thanks for your help figuring things out here :wink:


1 Like