Bitbucket PR decoration not showing

SonarQube Server / Community Build
1

Hello,

We are having an issue with the SonarQube PR decoration not showing up in Bitbucket.
We are using:

• Bitbucket Server v.7.7.1
• Bamboo Server v.7.1.4
• SonarQube v.8.5.1 developer - Developer Edition

We were able to:
• Create a SQ project and connect it with Bitbucket
• Get analysis done with Bamboo (via a task which does maven sonar analisys ) and send results back to SQ

But we still can’t get decoration on pull or merge requests.
• We setup Pull Request Decoration settings (conf name, Project Key and Rep SLUG)
• When we create a pull request there is no extra decoration in Bitbucket on PR review, nor do we see that PR in SonarQube Branches& Pull Request section.

2

Hey there.

Is Bamboo running a build on the Pull Request (one the pull request is raised0 that includes a SonarQube analysis?

3

Hello Colin.

Thank You for the response. Based on it, I have went back and checked our triggers on Bamboo, and, sure enough, it wasn’t triggering on pull request. I’ve configured the plan so that it now triggers on Pull request.

However, this didn’t seem to change the situation, since we still do not have any PR decoration in Bitbucket nor does the build itself register on SonarQube as a pull request. The analysis of the PR seems to have somehow been linked to the master branch ( as shown in SQ ) instead of registering as a PR. To make the confusion greater - the “master” branch (as shown in SQ actually) contains our PR code and not the code from our master branch in Bitbucket repo.

I would really appreciate any insight You might provide.

Thanks in advance for Your help.

4

I’m not sure how Bamboo (or Sonar for Bamboo, if you’re using it) handles the Pull Request Analysis parameters. If they aren’t being automatically set, you can find the ones you need to set (sonar.pullrequest.*) in this documentation and make use of Environment Variables available in your build environment to set them correctly.

You might check what other users have done.

5

Just wanted to give a heads up if anyone else was having similar issues - the solution is to use conditional tasks. What we’ve done is to make the plan trigger on PR creation and have a couple of tasks in there which are conditional. The condition being the existance of bamboo.repository.pr.key variable. If it exists within the mvn goal - the analysis is done on the branch. If it doesn’t - the analisys is triggered on the master branch. We have ( somewhat redundantly ) create 2 mvn tasks within our job - one with additional variables as follows:

-Dsonar.pullrequest.branch={bamboo.repository.pr.sourceBranch} -Dsonar.pullrequest.key={bamboo.repository.pr.key}
-Dsonar.pullrequest.base=${bamboo.repository.pr.targetBranch}

and another one which doesn’t include those variables. Based on the existance of bamboo.repository.pr.key variable within the goal, SQ executes the analysis. Since we have both tasks in our job, every time we create a pull request, the reuslting analysis is as follows:

  • the task which includes the variable in the condition is executed, therefore the branch is analized
  • the task which does not include the variable in the condition is executed, therefor the master branch is analized.

That is where the “somehat redundancy” comes from - we analize the master branch every time, which shouldn’t really be neccesarry ( after the branches merge ), so we have disabled that particular task from our job.