Set_bitbucket_binding 404 error

SonarQube 9.9.2 on premise
Bitbucket 8.9.6
Bamboo Data Center 9.2.5
MSBuild Sonar scanner (I don’t see a version number)
Sonar for Bitbucket 6.3.0

I am trying to set up Bitbucket_PR_Decorations. We have this working in another (Maven) project using a different scanner, but this is a .NET framework project using MSBuild.

We have the scanner and the analysis working. The results appear as expected on SQ. We have a python script set up to capture the relevant Bamboo variables and build out the set_bitbucket_binding call to decorate the PR. Again, a version is working smoothly in the other project.

I have confirmed that the parameters are building out the same as the other project, obviously with different values. Log files show that the API is authenticating, but returns a 404.

I have carefully reviewed the python script with another experienced dev and we feel confident that the API call is correct. I assume I have set up the sonar connector to BB wrong (although SQ shows that the configuration is valid) or that there is another piece to the puzzle missing.

In addition to the BB configuration in Sonar, we have a Sonar for Bitbucket application in BB and the Bamboo for Sonar app in Bamboo. It is not clear that we are or should be using them all. They were here when I arrived.

I would appreciate any help identifying things to validate.

There is some confusing posts about tokens. – user token vs admin tokens - could someone point me to a doc that explains that clearly enough for a new SonerQube user?

Thanks for any help


Welcome to the community!

Have you tried the API/URL manually? I suspect your 404 is actually a 401 under the covers that’s been obfuscated to be “more secure.”

You say you’ve got one project up and running with this script. Are you using the same authentication token for both projects? Because there’s a token type that’s project-specific. So if you’re using a project token, it’s natural that calls for the second project would fail authentication.

I can’t speak to those, but I suspect they’re unneeded. However, I would wait to remove them (one at a time) until you’ve got everything working.


There was a cluster of small errors, including my typo in the API call that took 3 devs to spot. That got us to a 204 response. That worked, thanks

1 Like