SonarCloud Organization and Branch Enhancements

[StuporHero (Michael Juliano)]

I’ve been using SonarCloud now for a couple of weeks. I’ve been able to achieve what I wanted with the tool in terms of the improvements to the code quality, so in that respect, you guys have nailed it. That alone is worth the price of admission. However, the way organizations and branches are handled is below the standard set by other tools in my ecosystem, and I would like to see what people think about the following enhancement proposals.

• Organizations
  • Should have a 1-to-many relationship with third-party services (e.g. GitHub, Bitbucket, GitLab) because many real-world organizations use more than one tool
  • Users should be able to belong to and manage more than one organization (if this is done first, it lessens the problem of the 1-to-1 relationship between organizations and third-party services)
  • Projects should be transferrable between third-party services so users don’t feel like your tool has locked them into a vendor they may wish to escape
• The Branches & Pull Requests page of Administration
  • Should allow me to change my MAIN BRANCH. Apparently, some people are offended by the master branch these days, and teams like mine work against a branch called develop that should serve as the basis for comparison rather than master which is reserved for releases.
  • Does not respect my regex for long-lived branches when the regex is a string literal or an option between two string literals (e.g. develop, (master|develop))
  • Should allow me to manually mark a branch as long-lived because sometimes people want a branch that doesn’t fit a standardized pattern to be long-lived

[Fabrice_Bellingard]

Hi @StuporHero,

First, thanks for taking the time to share with us valuable feedback, really appreciated

@StuporHero

Users should be able to belong to and manage more than one organization (if this is done first, it lessens the problem of the 1-to-1 relationship between organizations and third-party services)

Even if it’s not straightforward nor easy to put in place, you can already achieve this.

For instance, let’s say that you have both GitHub and Bitbucket Cloud repos:

• With your GH-based account, you’ve created a SC org which maps your GH org and hosts your GH repos
• With your BBC-based account, you’ve created a SC org which maps your BBC org and hosts your BBC repos
• The trick => in SonarCloud, you add your GH-based account as a member of your BBC-based organization, and grant this user admin privileges. This way, you can administer both organizations with the same GH-based account.

Would this setup work for your needs? Obviously, I agree that supporting these use cases out-of-the-box would make more sense, and this is something we have in our radar but not yet prioritised for now.

@StuporHero

Projects should be transferrable between third-party services so users don’t feel like your tool has locked them into a vendor they may wish to escape

Yes indeed, this one cannot be achieved currently (other than deleting and importing the repo in the other org). How critical do you feel this is for you?

@StuporHero

Should allow me to change my MAIN BRANCH . Apparently, some people are offended by the master branch these days, and teams like mine work against a branch called develop that should serve as the basis for comparison rather than master which is reserved for releases.

When you import a repo, SonarCloud sets up the name of default branch from what’s configured in your repo. So this should work fine from the beginning.

The problem arises when the default branch gets changed later on. It’s currently not possible to change in SonarCloud which branch is the default one, but it’s possible to rename branches. For instance, you can rename the default branch (in SonarCloud) from “master” to “main” for instance. It’s just that it’s a manual operation currently.

@StuporHero

Does not respect my regex for long-lived branches when the regex is a string literal or an option between two string literals (e.g. develop , (master|develop) )

This should be working. Maybe what is important to say here is that this regexp is used to set the branch type when it gets created for the first time. So if you updated this setting after the “develop” branch was analyzed for the first time, SonarCloud won’t convert it to a long-living branch.

If you still cannot make it work, I suggest that you open a dedicated thread in “Get Help > SonarCloud”, it’s more of a bug than a missing feature.

@StuporHero

Should allow me to manually mark a branch as long-lived because sometimes people want a branch that doesn’t fit a standardized pattern to be long-lived

Chances are that we get rid of this short-lived vs long-lived branch distinction. This concept does not exist anywhere else, so we feel this is more confusing that helping teams. What’s your feeling?

[StuporHero (Michael Juliano)]

Thanks for your reply! I did dump a lot, and you were very thorough which I appreciate.

@Fabrice_Bellingard

For instance, let’s say that you have both GitHub and Bitbucket Cloud repos:

When I attempt to log in with my GitHub account, I see the following which made me feel like I could only have one or the other account associated with the email. I thought this meant my Bitbucket account would be removed, but if that’s not the case, then I’d like to add removing this particular restriction to my list. I’m sure that’s not an easy fix, but in the meantime, perhaps clarifying the message slightly is in order so users understand that they’ll still have access to their Bitbucket account in case they’re as cautious as I am.

@Fabrice_Bellingard

Yes indeed, this one cannot be achieved currently (other than deleting and importing the repo in the other org). How critical do you feel this is for you?

Relatively critical, actually. We’ve been transforming our infrastructure and processes, and we’ve discovered that GitHub’s Pull Request functionality is a lot better than Bitbucket’s, however, we’ve already created an SC project for the Bitbucket repo, and I believe the repo has enough lines that we’d even have to upgrade our plan in order to migrate unless we removed the Bitbucket project before the billing cycle ended and created the GitHub project after the new billing cycle started in order to prevent the lines from being double counted.

@Fabrice_Bellingard

The problem arises when the default branch gets changed later on. It’s currently not possible to change in SonarCloud which branch is the default one, but it’s possible to rename branches. For instance, you can rename the default branch (in SonarCloud) from “master” to “main” for instance. It’s just that it’s a manual operation currently.

Unfortunately, my repo had master incorrectly set as the default branch when I imported the repo.

@Fabrice_Bellingard

This should be working. Maybe what is important to say here is that this regexp is used to set the branch type when it gets created for the first time. So if you updated this setting after the “develop” branch was analyzed for the first time, SonarCloud won’t convert it to a long-living branch.

Okay. That explains what’s happening. That makes sense.

@Fabrice_Bellingard

Chances are that we get rid of this short-lived vs long-lived branch distinction. This concept does not exist anywhere else, so we feel this is more confusing that helping teams. What’s your feeling?

I agree. I don’t really know what benefit I gain from designating a branch as long-lived, anyway, as long as SC prunes branches as they are pruned from the source repository. It’s probably good to keep pull requests around, though, for reference.

Thanks again for your answers.

[Fabrice_Bellingard]

@StuporHero

When I attempt to log in with my GitHub account, I see the following which made me feel like I could only have one or the other account associated with the email. I thought this meant my Bitbucket account would be removed, but if that’s not the case, then I’d like to add removing this particular restriction to my list. I’m sure that’s not an easy fix, but in the meantime, perhaps clarifying the message slightly is in order so users understand that they’ll still have access to their Bitbucket account in case they’re as cautious as I am.

You’re totally right Michael, I’ve logged this on our side as a problem to fix.

@StuporHero

Relatively critical, actually. We’ve been transforming our infrastructure and processes, and we’ve discovered that GitHub’s Pull Request functionality is a lot better than Bitbucket’s

I understand, and I’ve logged this feedback too. To be transparent, the priority is less important than other needs (given that it does not happen every day) - yet I agree it totally makes sense to be able to transfer projects between third-party services at some point.

@StuporHero

Unfortunately, my repo had master incorrectly set as the default branch when I imported the repo.

Was it when you imported it from Bitbucket or GitHub? I’ve just made a quick test on GitHub and it works. If you can’t make it work, here too I suggest that you open a dedicated thread in “Get Help > SonarCloud”.

[StuporHero (Michael Juliano)]

@Fabrice_Bellingard

I understand, and I’ve logged this feedback too. To be transparent, the priority is less important than other needs (given that it does not happen every day) - yet I agree it totally makes sense to be able to transfer projects between third-party services at some point.

I appreciate the transparency.

@Fabrice_Bellingard

Was it when you imported it from Bitbucket or GitHub? I’ve just made a quick test on GitHub and it works. If you can’t make it work, here too I suggest that you open a dedicated thread in “Get Help > SonarCloud”.

I’m sorry. I didn’t phrase that clearly. I mean my Bitbucket account had master set as it’s default branch when I imported it into SonarCloud. I realized only afterwards while working on pull requests that it needed to be set to develop. This is why I’m asking for the ability to change it. As far as I can tell, it works as expected.