"Could not find a default branch to fall back on" for a specific branch

  • ALM used: GitHub
  • CI system used: GitHub Actions
  • Scanner command used: ./gradlew sonarqube --info
  • Languages of the repository: Java
  • (URLs not public)
  • Error observed:
    FAILURE: Build failed with an exception.

    > Task :sonarqube FAILED

    What went wrong:

    Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

    Execution failed for task ':sonarqube'.

    > Could not find a default branch to fall back on.
  • Steps to reproduce:
    • I see this on one of our projects. Other projects are fine.
    • Only in pull requests for a specific branch (master). Other branches are fine.
    • Our Sonar configuration didn’t change in ~2 years. My last successful Sonar scan was 8 days ago, then it still worked, just like it worked in the last few years.
    • Changes in the PR have no correlation with the failure, different PRs with different changes fail just the same.
  • Potential workaround: none


I’ve read all possible answers in the forums, sonar.projectKey, sonar.organization and sonar.host.url all seem to be fine (and at least they are the same on all branches, so I don’t expect a different result). The project does have a default branch set. At first glance it seems like as if the real issue isn’t really Sonar not being able to fall back on a branch (I don’t even see why would it need to fall back on a branch anyway, it should analyze the branch that it should analyze.) but this is only hiding an underlying issue that is not visible because of this error message.

What else could I try to make the code analysis possible again?


Hi Miklos,

Welcome to the community!

(Sorry about the missing accent. AmE keyboard. :flushed:)

Thanks for this thorough rundown of the details.

You say the analysis configuration hasn’t changed in 2 years. What about your build configuration? I see this in the error:

This PR doesn’t happen to bump the Gradle version up to 8.0, does it?

Also, what version of the task are you using? We’ve recently released v3.5 and updated the task name to sonar (to be more friendly to SonarCloud users). sonarqube is still a synonym, but does make me wonder if you’re on the latest version.


The Sonar plugin version was 3.3, the Gradle version 7.6. This PR of mine was indeed upgrading Gradle, but different pull requests still running with the old Gradle version 6.6 also had the problem.

Now I tried to upgrade the Sonar plugin to, but I still get the same failure.


Okay, so you have multiple PRs on (to?) master, with different underlying feature branches, showing this problem? Any significant differences between master and the branches whose PRs don’t have this problem?



Sorry, my bad, I mixed up some PRs from an other project.
Checking again, this particular project only has the Sonar check on master and on PRs to master. All of these started to fail on the 12th of December, with the last green build being on the 5th of December. (I hope the dates are right, GitHub deleted the old logs.) The PRs differ in size, one of them is the full migration of the project from Java 8 to 17, the other is a version change of two third party libraries which should not affect code analysis in any way.

I tried to figure out where this error message may come from, but a quick search in the plugin repository didn’t give me any relevant results (Search · default branch · GitHub) therefore I assume that the error message is coming from the server side. What exactly are the conditions that are needed for this error message to happen?


I’m out of my depth at this point. I’ve flagged this for more expert attention.


1 Like

Hi @balazsmiklos85 ,

Thanks for all the details you provided.
I’ll send you a private message to get some private information about your project if you’re OK with that. It will help me investigate on the server side.

In the meantime, could you please share here, with the private elements redacted (organization key, project key, …):

  • the GitHub Action configuration file for the whole workflow
  • the full scanner logs, with the Debug mode enabled (by adding -Dsonar.verbose=true to the scanner command line), for both the main branch of your repository and a failing PR?

Thanks in advance,

Hi @balazsmiklos85, thanks for all the details you sent on the private thread.

Is master your main branch on SonarCloud?

I see this in the workflow:

on: [pull_request]

In our tutorial, we advise configuring the triggers as such:

  • on push for the main branch, probably master for you
  • on some PR events
      - master
    types: [opened, synchronize, reopened]

Could you give it a try?

Hi @balazsmiklos85

My apologies for the long delay, I missed your private answer.
Could you please post here a screenshot of the branches seen by SonarCloud, on this page:


Screenshot sent in a private answer.

Thanks for the screenshot.
I see 1 single branch, named master and identified as the main branch. I would indeed expect the scanner to default to that branch, and I’ll dig into that strange behavior.

In your private answer, you mention:

we also have some release/ branches that would fit the filter for the long-lived branches.

The configured pattern is: (branch|release)-.*. It would match release-xx, not release/xx.
Therefore, I suspect those release branches were detected as short-lived branches and then automatically purged after 30 days.
I’m surprised though because the purge of the branches without analysis in the last 30 days happens only after a report has been successfully processed on the server side.
From what I understood, the analysis are failing at the scan time (ie. before the report submission to SonarCloud) for 2 months now. That’s consistent with the date of the last analysis of the master branch I see on the screenshot.
Do you have some successful scans happening for that project?

Hi again

To be honest, I’m a bit clueless on that branch fallback issue.

Could you try to create a public project with some dummy sources (the source content is not important here), and use the same build system and CI as in your impacted project (Gradle and GitHub actions, if I’m correct) to try to reproduce? And if you manage to reproduce the issue, could you then share the link to that public project here so I can investigate from a starting point?

Thanks in advance,

While trying to make this reproducible, it turned out, that our SONAR_TOKEN secret in the GitHub Action somehow got corrupted. As I’m an admin in neither in our organization’s Sonar projects, nor in the GitHub projects, I have no information on how did this happen, but after requesting a new token, the build seems to be fixed.

Thanks for everything.

1 Like

Thanks a lot @balazsmiklos85 for sharing the resolution!

Wishing you lots of green quality gates,

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.