Persistent BitBucket warning message in SonarCloud

We have a persistent warning message in SonarCloud:
“Pull request decoration did not happen. Please install SonarCloud application on the Bitbucket Cloud repository’s organization or user: ###”

I’m not sure how this is impacting our uploaded analysis, as it still appears to be updating.

We’re also uploading our analysis using:
mvn sonar:sonar --batch-mode --errors -pl -am -Dsonar.projectKey= -Dsonar.organization= -Dsonar.verbose=true -Dsonar.host.url=https://sonarcloud.io -Dsonar.login= -Dsonar.pullrequest.branch= -Dsonar.pullrequest.base= -Dsonar.pullrequest.key= -Dsonar.pullrequest.bitbucketcloud.repository= -Dsonar.pullrequest.bitbucketcloud.owner=

We also have the SonarCloud app installed in Bitbucket and the widget displays on PRs.

Not sure what else I should be doing to address this warning?

Hi,

Which sort of value are you passing in sonar.pullrequest.bitbucketcloud.owner and sonar.pullrequest.bitbucketcloud.repository ? Some kind of friendly repo/owner name or guids ?

Thanks.

Mickaël

Hi, I’m passing in the UUIDs for the repo and owner that I retrieved from the BitBucket REST API.

This won’t affect the analysis itself (as you can see from the widget), just the PR decoration.

Everything looks in order to me, I don’t know how this state is possible. I will try to reproduce and get back to you.

In the meantime, I have a few questions:

  • Have you tried reinstalling the SonarCloud app?
  • Can you tell me your organization and the project key on SonarCloud?
  • Has PR decoration ever worked for this repo?
  • Do you have another repo where PR decoration works?
  • Where and how do you run your build pipeline?

Hi Janos,

  • Re-installing: No, if you’re referring to deleting the project from our SonarCloud account and then re-creating it, I don’t want to do that as we’d lose the analysis history
  • Organization/Project: It’s “instaclustr” and “instaclustr-app”
  • PR Decoration: Yes, when we previously used SonarQube. Since migrating to SonarCloud, decoration wasn’t supported in the plugin
  • Build pipeline: We run it via Jenkins and within the pipeline run the Maven Sonar plugin:
    mvn sonar:sonar --batch-mode --errors -pl -am -Dsonar.projectKey=<key> -Dsonar.organization=<org> -Dsonar.verbose=true -Dsonar.host.url=https://sonarcloud.io -Dsonar.login=<login> -Dsonar.pullrequest.branch=<branch> -Dsonar.pullrequest.base=<base> -Dsonar.pullrequest.key=<key> -Dsonar.pullrequest.bitbucketcloud.repository=<repo> -Dsonar.pullrequest.bitbucketcloud.owner=<owner>

No, I means recreating the Connect App on Bitbucket. (Btw we would not recommend recreating a SonarCloud project, precisely for the reason you mentioned!)

I see, so the SonarCloud project was never successfully decorated, yet.

Are you sure that the UUIDs you are using are correct? Note that according to the documentation, the values should look like {d2615dd4-550d-43e5-80c4-665f951e5d6e}. I point this out because I myself find the enclosing {...} a bit strange, but they must be included, and this may be easy to overlook.

Hi Janos,

Thanks for the tips.

  • Re-installing: I have now uninstalled the Sonarcloud app from Bitbucket and re-installed it
  • PR Decoration: Thanks for pointing this out - I wasn’t using curly braces. I’ve retried with the UUIDs wrapped in braces

The message is different now, but still says that PR decoration didn’t work:

I’m fairly sure the command parameters are correct, as we still have the SonarCloud widget displaying on the Bitbucket PR and it’s last update time matches my test scan.

I stand corrected. The { and } should not be part of the parameters.

How do you obtain the UUID values you are using? In my test I did like this:

curl https://api.bitbucket.org/2.0/users/USER | jq .uuid
curl https://api.bitbucket.org/2.0/repositories/TEAMNAME/REPONAME | jq .uuid

Where USER is my username on Bitbucket Cloud, TEAMNAME the name of the team of the repo where I have the pull request, and REPONAME is the name of the repo. And then the first value is used for the owner, the second for the repo parameters. Does this match your use case exactly, or what is the difference?