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
Hi,
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?
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 3.5.0.2730, 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?
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?
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: https://sonarcloud.io/project/branches_list?id=<your_project_key>
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?
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?
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.
)