Could not find ref 'refs/heads/master' in refs/heads, refs/remotes/upstream or refs/remotes/origin


I’m getting the warning below when running SonarQube from within a Docker-container using Azure DevOps.

Could not find ref ‘refs/heads/master’ in refs/heads, refs/remotes/upstream or refs/remotes/origin
You may see unexpected issues and changes. Please make sure to fetch this ref before pull request analysis.

When building the Docker container I pass the arguments at build time

docker build \
  --build-arg sq_pr_branch=/d:sonar.pullrequest.branch=refs/heads/<branch> \
  --build-arg sq_pr_key=/d:sonar.pullrequest.key=<key> \
  --build-arg sq_pr_base=/d:sonar.pullrequest.base=refs/heads/master \
  -f test/Test.Dockerfile -t <container> .

We’re running SonarQube Developer Edition Version 8.6 (build 39681)


1 Like

The SonarQube Scanner uses git to detect what code was changed in the pull request. For that, it needs local access to the target of the pull request, which is master in your case.
Make sure that master is fetched before running the scanner.

What to do if the repository doesn’t contain the master branch, only main?

If you’re analyzing a pull request targeting main, main needs to be fetched and present in the local repository.


I am using SonarQube SonarQube v7.9.1 (Bulid 27448) Enterprise edition and Sonar Scanner v3.0.3.778.

My Main branch is configured to be master. In Team City, I clone the repo and only one branch, namely “integration”, exists in this local repo. No other branches are cloned. When performing a scan of C++ code, I use the option“integration” (i.e. I specify the same name as the branch I have checked out.)

As I understand it, because branch “integration” is not found in the regex, Sonar refers to my branch “integration” as a short-lived branch (SLB).

My questions are:

Q1. Are short-lived branches (i.e. “integration” in my case) analysed with respect to the Main branch (i.e. master)? That is, does Sonar analyse the delta between master and integration only? (i.e. it looks only at files changed since “integration” was last branched off of “master”)?

Q2. Does Sonar scanner need the “master” branch to be in the local repo clone too? i.e. do I need to do: “git fetch origin master:master” so that the scanner can access the branch “master” to determine the delta between the current checked out branch (“integration”) and the" master" branch?

If so, please would you point me to the Sonar documentation that explains all this so that I can understand it more fully?


Hi Will,

The answer is yes for both questions.

The documentation about branches for that version is here: Overview | SonarQube Docs

The concept of long lived branches and short lived branches no longer exists in more recent versions of SonarQube.

1 Like

I have the same issue in my teamcity environment , how can this be fixed?
Everytime we do a PR into develop we want to run sonar-runner but it is not picking up any code smells and we see this warning on sonar server:

Could not find ref ‘develop’ in refs/heads, refs/remotes, refs/remotes/upstream or refs/remotes/origin. You may see unexpected issues and changes. Please make sure to fetch this ref before pull request analysis and refer to the documentation.

No devops platform configured. To report the Quality Gate status to a devops platform, please configure it in the project administration.

Answered here: Pull Decoration Not happening - #6 by dmeneses

I am experiencing similar behavior. I’m doing git clone -b develop before the scanner is run but in sonarcloud the coverage shows up under master branch. I have admin access and I can rename that branch in the web ui but is there a way to set develop as main branch beforehand?

Are you having problems with SonarQube or SonarCloud?
The results of the scan are showing up in the branch master instead of develop? How is that related to this topic?

Hi, Thanks for the response and sorry if this is a cross post. I see the refs/heads warning/error during scan. The results of the scan is showing in sonarcloud web-ui after the scan is complete. I was hoping to to default name to develop instead of master, otherwise I get the Project was never analyzed... error for option.

Definitely using checkout github action with fetch depth
Fetch all history for all tags and branches

  • uses: actions/checkout@v3
    fetch-depth: 0

@Riad_Gaffar did you manage to fix the issue of coverage showing up on master? If so what helped fix it?

I resolved this by calling git fetch origin ${env.CHANGE_TARGET}:${env.CHANGE_TARGET} inside the jenkins script. This will allow sonar scanner to scan the branch with respect to develop/master/main or whatever base you’re merging into.

1 Like