we are using SonarCloud on a paid plan and company policy requires us to have private projects only. Until recently that wasn’t an issue as all new projects were private by default. But during the last couple of days we noticed new projects being flagged as public instead. We are using mainly the Web API to create projects and it seems that a call to api/projects/create requires the explicit setting of visibility to private to avoid getting public projects. Is this intended behaviour?
Having private projects by default feels much more natural to us and the documentation on Payment and Visibility | SonarCloud Docs also indicates that it should require an active switch from private to public to have public projects on a paid plan. I couldn’t find any announcment on a policy change on this topic. The closest post to this topic that I could find was from 2020 (Any way to disable public projects as an option ) where it was stated again that the default should private.
It would be great to get some information on whether this is a bug or if we need to prepare to actively monitor our project states in the future.
We expect most users to use bound projects, where the visibility of the project is tied to the visibility of the repo on the DevOps Platform.
Creating the project via the UI also defaults to private (for example, creating a manual project in a private organization)… but it’s doing that by passing the private flag to POST api/projects/create.
So if you’re creating projects via calls to POST api/projects/create, you will have to pass that visibility explicitly, just like the UI is doing.
And now the big question: why are you primarily using the Web API to create projects? It would be great to understand your use-case more!
(By the way, maybe we should be defaulting to private visibility even when using the Web API if it’s a paid org, I’m not arguing with that, I would just like to understand your use-case more).
Thanks for your quick response, Colin !
Our main reasons to use API calls are harmonization issues and better automation support. We work in a company with some hundert developers distributed over several teams around the globe and each team comes with some legacy tool stack. The Web API allows us to hide most interaction with Sonarcloud in a Python tool that the dev teams can run locally or on their GitLab/Azure DevOps/Jenkins/… CI pipeline without worrying about the configuration details for Sonarcloud (and other tools that we try to establish as company standard).
Changing the tool code to use the new API specification and explicitly request private visibility is no problem, of course. The problem is that the change in server behavior came out of the blue and we don’t know what to expect for the future. For months the current version of our tool was creating private projects (as intended by us) and suddenly the same version started to create public projects instead - which creates a complience violation each time. That caught us completely by surprise and if this new behavior is bound to stay we need to roll out an update of our tool immediately and monitor if somebody is still using an old version.
Dear Colin and Andreas,
If you don’t mind I would like to complement your facts with some discovery that I made.
I have a client that used the UI to create a project and reported that he intended to create a private project but it was public.
I tried to reproduce the issue and I found:
“If you create a project with the wizard “SonarCloud” in a private organization by filling the fields “display name” and “project key”, and leaving visibility “private”, the project is created PUBLIC. However, if you click public and then private again, the project is created PRIVATE”
It seems to me that somehow the wizard does not set correctly the variable visibility by default.
That’s serious sounding! I cannot reproduce this – I left the visibility “private” and it created a private project.
Are there any other details you can share? Browser, DevOps platform…
Hi @Colin the problem only occurs in one of the two organizations I am administrator, both private organizations.
The organization in which this problem occurs is integrated with GitHub users and for the CI/CD they use Azure Devops.
I can reproduce the scenario described by Maria (using an up to date Google Chrome browser) for our organization. The default setting during project creation shows private but I end up with a public project.
Thanks. I consider reports like this pretty serious so I’ve gone ahead and:
- Unlisted this thread, for now
- Engaged the relevant team(s) so we can start digging into this
@mvillanueva and @Teladur – are you working separately or together? Just want to assess if this is affecting one organization or many.
We are working for different companies - the affected Sonarcloud organizations are completely unrelated
I have reached out to both of you for information about the affected organizations (primarily, the organization key)
We’ve identified the problem. The fix for the UI will be deployed on Monday. We’re currently working on the API fix. In the meantime, if you need to use the API, please be sure to explicitly set the visibility flag to private in your calls.
That’s great news. Thanks a lot!
Hi all, that’s great. I do not need to use the functionality for the moment.
Thanks a lot.
María José Villanueva.