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.
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.
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).
I’m another Antoine from Sonar
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 https://gitlab.com/api/v4/projects/PROJECT_ID/repository/branches
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.
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 :
https://gitlab.com/api/v4/projects/46849669/repository/branches doesn’t show the default branch
but https://gitlab.com/api/v4/projects/46849669/repository/branches?page=2 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.
