We are using SonarCloud in our organisation, and we use main branch in all our repositories. However, SonarCloud always defaults to master as the main branch.
Recently, we’ve noticed all new projects have master as the main branch, and main as a short-lived branch. There seems to be no way to change the main branch to main, renaming it fails with Impossible to update branch name: a branch with name "main" already exists in the project. However, docs specify that for a branch to be set as the main branch, it needs to have an analysis (so it needs to exist), which seems contradictory to the above error. Setting the existing main branch to be the main one doesn’t seem like an option (unless it is and I just don’t have permissions to do it).
What options do we have to fix this? Can you confirm what the impact is for not having the main branch correctly set up?
Also, was there a change recently so that if an analysis runs on a given projectKey that doesn’t exist, it gets automatically created? Before, we were seeing errors when running an analysis on a project that doesn’t exist.
Hey @Ana_B, it’s not possible to manually change the main branch, indeed, but renaming it should work. This is a workaround that we sometimes recommend. In your case, since you already have a main branch, you should first delete it, then rename your SonarQube Cloud master branch to main. This will destroy the old main’s analysis history, but it’s the only workaround available.
Normally, when creating a new project via DevOps integration (repo binding), the main branch is detected and assigned correctly. Are you perhaps creating projects manually, or directly by running an analysis?
And finally, normally when you run an analysis with a new projectKey, a new project will get created. If this fails for you, it’s possible that the token that you’re using for the analysis is associated with a user that only has the Execute Analysis permission but lacks the Create Project permission.
Won’t destroying the old main’s analysis history cause it to fail on the next merge to main? According to the docs, for a branch to be set as main branch, it needs to have an analysis.
We were creating them via the API, or manually, but recently we’ve noticed they are created automatically when running an analysis.
And finally, normally when you run an analysis with a new projectKey, a new project will get created. If this fails for you, it’s possible that the token that you’re using for the analysis is associated with a user that only has the Execute Analysis permission but lacks the Create Project permission.
Has this always been the case? We’ve only noticed this happening recently. Before that, we had to ensure the project exists before running an analysis.
To give you a bit of context - we use Nx in our repos, one repo will have several Nx projects (each app and library in that repo will be its own Nx project). Each Nx project corresponds to a Sonar project so one repo will have tens of Sonar projects. Therefore, it’s very common for new projects to be created. The way that the Nx repo is set up, project keys are automatically set based on the project name when a new project is added to the repo, it will automatically run and so it will automatically create a Sonar project. Engineers don’t have visibility over this and it’ll be created incorrectly with master as the main branch and other default settings we don’t want. What do you recommend us to do in this case? I’m also wary that we might end up with many orphaned projects e.g. if a project is renamed, deleted, there’s a typo and it’s corrected etc.
Won’t destroying the old main’s analysis history cause it to fail on the next merge to main? According to the docs, for a branch to be set as main branch, it needs to have an analysis.
I think maybe I explained this in a slightly confusing way… let me clarify. By using the workaround, you are deleting main on SonarQube, so you lose any analyses you have ran in the past. Then you rename master to main. The branch already exists, and it’s already “SonarQube’s main branch” (regardless of the branch’s actual name). Any analyses against that branch should succeed.
Could you clarify where in the docs did you read that for a branch to be set as main, it needs to have an analysis? It sounds a bit odd, since there’s not really a way to set it manually on SonarQube Cloud. Perhaps you saw it in SonarQube Server docs?
Has this always been the case? We’ve only noticed this happening recently. Before that, we had to ensure the project exists before running an analysis.
I don’t think it’s a recent change. To me it sounds like an issue permission, and in fact, you could try it yourself by testing the scenario with a token for a user that has the “create project” + “execute analysis” permissions, and with a token for a user that only has “execute analysis” but cannot create projects.
[…] What do you recommend us to do in this case?
If you don’t want accidentally-created projects, then don’t grant the “create project” to the token that is being use for that CI. If project creation is very common, you might want to look into automatizing it with some other different, perhaps run-on-demand CI.
Finally, this is not really a direct solution to your problem, but the project setup you described sounds like you might be interesting in setting it up as a monorepo.
Could you clarify where in the docs did you read that for a branch to be set as main, it needs to have an analysis? It sounds a bit odd, since there’s not really a way to set it manually on SonarQube Cloud. Perhaps you saw it in SonarQube Server docs?
I can’t remember tbh, I remember reading it somewhere yesterday, but I can’t find the page now.
If you don’t want accidentally-created projects, then don’t grant the “create project” to the token that is being use for that CI. If project creation is very common, you might want to look into automatizing it with some other different, perhaps run-on-demand CI.
We have a script that we were running manually and we plan on creating an nx generator that would create the project with just one command with the correct configuration. Is there a way to simply disable this feature org-wide rather than changing the scope of the token?
Finally, this is not really a direct solution to your problem, but the project setup you described sounds like you might be interesting in setting it up as a monorepo.
I think we’ve already done this, but I’m not sure if there’s any benefit in doing so? There’s no monorepo view, is there?
There’s no feature to prevent project creation other than just not granting the permission to anyone. Could you elaborate a bit more on what type of feature you would expect? Simply a global toggle that lets you disable/enable project creation? I do think that generally, the permission covers this functionality satisfactorily, but if you have a proposal I could forward it to the PMs.