Right now project keys are shared between everyone using SonarCloud. I believe this problem stems from SonarQube being a self-hosted service first.
But when moving to the cloud and “everyone” using the same server we’re going to run out of meaningful names. So project keys should not be globally unique, but unique to the organization.
An example could be a project key call “test”. That seems like a reasonable place to start when trying out sonarcloud for the first time. But then you’re met with an error that you don’t have permissions or something similar because “lireric” already have a project called test. Sad face.
So now no one else can have a test project.
Indeed, when you look at SonarCloud from a “SonarQube” perspective, making project keys unique to the organization is one solution we considered. And this sounds obvious: as a user, I will choose my project key, and I don’t want to end up on a collision with a key that is already used.
Now, let’s see SonarCloud as a cloud solution linked to GitHub, Bitbucket Cloud and Azure DevOps solutions. When you want to analyze one of your repositories, you select it from the SonarCloud web interface, and SonarCloud will generate a unique project key for you. No possible collision, no need for you to wonder what to use: it’s easy.
The second solution is already in place for personal repositories, and will soon be extended to any repository. We haven’t worked on the first solution because the cost of implementation is big and since we target developers and teams creating projects from their repositories, we feel the the ROI is just too high for this solution for now.