Slash in branch name results in wrong Github pull request decoration

  • SonarQube Server Enterprise Edition, v2025.1.1 (104738), ACTIVE, MQR Mode
  • ALM: GitHub
  • CI system: Jenkins
  • Scanner command:
npx sonar-scanner   -Dsonar.host.url=${SONAR_URL}   -Dsonar.token=${SONAR_TOKEN} -Dsonar.projectKey=${SONAR_PROJECT_KEY}   -Dsonar.projectName=${SONAR_PROJECT_KEY}   -Dsonar.scm.provider="git"   -Dsonar.sourceEncoding="UTF-8"   
-Dsonar.pullrequest.key=9091 -Dsonar.pullrequest.branch=angular-17/main -Dsonar.pullrequest.base=main -Dsonar.pullrequest.github.repository=XXX 
  • Languages of the repository: Typescript / Angular
  • Error observed
    no errors in the logs related to “angular-17/main”
  • Steps to reproduce
    • create a branch with a slash in the name, where the name after the branch matches the name of another branch (e.g. “main”)
  • Potential workaround
    • don’t use a slash?

Here’s an image of the branch decoration
The Failed Conditions are actually from Sonar’s analysis of the main branch.
Note that the link for “See analysis details” is https://sonarqube.xello.tech/dashboard?id=XXXX&branch=main

I created another PR that had a slash in the branch name, on a different repo, and the equivalent link uses the pullrequest id, vs. the branch name, i.e. pullRequest=7

Hey there.

First things first –

If you’re trying to analyze .NET code, you must use the SonarScanner for .NET. npx sonar-scanner won’t do the job.

Secondly – I can’t reproduce the behavior you’re describing. And it sounds like you can’t either?

Is only this one project affected?

Sometimes GitHub Check information from one branch can appear on the other if the same commit ID exists in both branches. It might be that you need to make sure the correct sonar.scm.revision is being sent by the scanner. I recall this is tricky in Jenkins because of how it handles merge commits.

Correction, the repo is Typescript / Angular, not C# (I corrected the description).

No, I can’t recreate it, on this repo, nor another.

The only clue I have is that on the “broken” PR, the link for “See analysis details on SonarQube” looks like:
<baseUrl>/dashboard?id=<branchId>&branch= main

whereas on any other PR, the link looks like:
<baseUrl>/dashboard?id=<branchId>&pullRequest =<PR id>

Do you know what circumstances would cause branch to be used on a PR?

Also, you suggested that we use sonar.scm.revision.
We have been using only sonar.pullrequest.branch and sonar.pullrequest.base. Does that leave some ambiguity? Should we add revision?

When SonarQube runs analysis and updates GitHub check status, it does this for a specific source control revision (commit), and this process works for both individual branches as well as pull requests.

If the same commit appears across multiple branches, including within a pull request, GitHub will display the check status for each location where that commit is present. This behavior comes directly from GitHub’s design and isn’t something SonarQube can control. Consequently, you might see a branch shown on a PR if the analyzed revision exists both on the branch and within the pull request.

In your situation, it’s likely that the wrong sonar.scm.revision is being sent, possibly during the scan of your main branch—which could explain why the PR is being decorated in this way.

Additionally, note that Jenkins configurations can be tricky in this context. Read more here.

For those using Jenkins, this issue should be resolved with the GitHub Branch Source Plugin. Are you utilizing this plugin in your setup?

Thanks for that explanation.

Yes, we have the Github Branch Source Plugin installed, but it looks like we’re also using the deprecated Github Pull Request Builder, because I see variables like this:


PULLREQUEST_KEY=“${ghprbPullId}”
PULLREQUEST_BRANCH=“${ghprbSourceBranch}”
PULLREQUEST_BASE=“${ghprbTargetBranch}”

I’m investigating…

… conclusion: we have GitHub Branch Source installed, but we’re using GitHub Pull Request Builder.