- 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.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?
Welcome to the community!
(Sorry about the missing accent. AmE keyboard. )
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 220.127.116.1130, 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.
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.
master your main branch on SonarCloud?
I see this in the workflow:
In our tutorial, we advise configuring the triggers as such:
- on push for the main branch, probably
master for you
- on some PR events
types: [opened, synchronize, reopened]
Could you give it a try?
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
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?