Unable to add develop branch to long-living branches

Hey there, I’m new to SonarCloud and a little confused/frustrated by the branch recognition features.

I don’t think my use case is unusual - in fact, I’ve seen it in 3-5 other posts. I want to analyze main (my default branch), develop, and any release branches. This allows me to run SonarCloud scans as I merge features into develop, create releases, etc. The corresponding regex pattern would be (main|develop|release).*

I saw in another post that “Once a branch is created, its type cannot change [ . . . ] the develop branch already existed as a short-living branch before you set the pattern. The only way to make develop a long-living branch is by deleting it, and then running a new analysis.”

First of all, I don’t see any clear way to trigger running a new analysis from SonarCloud. It seems to be based entirely on webhooks from GitHub (my source control provider).

I saw in yet another post a similar explanation that “I think issue is that SonarQube project was created after Develop branch existed, and thus updating the RegEx does not have an impact on its status as long-lived, unfortunately.”

So, I tried to work with the recommendations above. I deleted the SonarCloud project entirely, I deleted the develop branch from my repo entirely, and I recreated the project. Before I created the develop branch again, I set the long-living branch pattern to (main|develop|release).* which I tested with regex to ensure it would work.

As can be seen below, the branch was not detected when I created it nor when I added a commit with a few changes.

I also can’t see the develop branch in this drop down.


My honest feedback is that this is frustrating and unacceptable behavior of the software. I can’t find a reasonable explanation as to why I shouldn’t be able to alter the long-living branches after the fact other than “sorry, that’s not how it works”. I’ve now got a handful of bogus PR’s and bogus commits in my repo due to trying to resolve this issue. I also don’t understand why I can’t see any of my “short-lived” branches such as develop to be able to run scans on them.

Any support would be much appreciated.

1 Like

Also - if it’s this difficult to add change branch type after the fact, could you please just make it configurable when people first create the project (as in we’d be able to set the regex pattern before the initial scan is run), or default the regex pattern to git flow standards (i.e. main, develop, release/)?

Hi SJ Porter,

Welcome to the community support!

Could you provide some context please?
The template of a post comes with the following:

Template for a good new topic, formatted with Markdown:

  • ALM used (GitHub, Bitbucket Cloud, Azure DevOps)
  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI
  • Scanner command used when applicable (private details masked)
  • Languages of the repository
  • Only if the SonarCloud project is public, the URL
    • And if you need help with pull request decoration, then the URL to the PR too
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
  • Steps to reproduce
  • Potential workaround



Sure thing.

  • ALM used: GitHub
  • CI system used: GitHub Actions (but not applicable in this scenario, using automatic analysis method)
  • Languages of the repository: Python
  • Error observed: No error; branches not showing as demonstrated in screenshots above
  • Steps to reproduce: Point SonarCloud to an existing repo with a develop branch, or point SonarCloud to an existing repo in which the develop branch has been deleted and then recreate the develop branch
  • Potential workaround: None identified

@Martin_Bednorz to me the user expects things AutoScan can not do.

Only master default branch and PRs are supported but he expects other long living branches to be supported.


the user expects things AutoScan can not do

Yes, I would certainly expect that from the premium version of your service. Unless I’m mistaken, I could run SonarQube CE in Docker for free and scan any branch at any point (by switching the branch using git). It’s nowhere near as convenient as pointing SonarCloud directly to GitHub and using the AutoScan feature, but it’s possible. All I’d ask is for this kind of feature to be added to the product backlog so that one day it’s available.

My team uses git flow, so master is typically only updated during a prod release. It’s kind of wonky/awkward to create a PR directly to master (say, from develop or even a feature branch) every time we’d want to see scan output. I’d much rather have continual oversight and guidance on the develop branch than for my team to only see feedback when we are attempting a prod release and/or after we’ve pushed a prod release.

From my perspective, the user story would be:

As a SonarCloud user following the git flow workflow, I want to be able to scan the develop branch in addition to the main (default) branch on an ongoing basis so that I can review feedback between releases.

Acceptance Criteria:

  • SonarCloud scans should be able to be run against the develop branch on an ongoing basis.
  • Users should not have to create a PR to master in order to see a scan of the develop branch.
  • Ideally, users would be able to choose a branch to be scanned with a manual trigger (and perhaps a monthly limit of manual scans to reduce cost footprint).
1 Like

Hi SJ,

Sorry for your frustating experience and the time you lost.

AutoScan has a specific limitations and we are transparent about those.

Despite those limitations we can see the adoption is growing, which means not every body is working the same way (Gitflow for instance). Users can still have a nice experience with AutoScan even if they can not do everything the standard mode or SonarQube do.

By the way, the goal of SonarCloud is not to mimic SonarQube which can be confusing when users were used to SonarQube.


I’ve cancelled my subscription, sorry. There’s massive potential for the product and I’d love to pay for it if/when AutoScan has the core features I need.

Analyzing other long-lived branches alongside the main branch isn’t an edge case. Here’s four other posts which outline similar needs from other users:

Again, all I ask is that you add something to your backlog for it or even just discuss it with your product managers.