Bitbucket PR is not annotated if Jenkins creates local merge commit

SonarQube Server / Community Build
, , ,
1

In our setup, pull requests in Bitbucket 7.21.0 are built by Jenkins 2.332.3 and plugins for Maven and Gradle (depending on the project) trigger the code analysis in SonarQube Developer Edition 8.9.1. The result of it is sent back to Bitbucket to annotate the PR and block merging if there are issues.

On several occasions and in different projects, we noticed that the report is missing in Bitbucket although it is available in SonarQube. This blocks merging even if the analysis passed.

I collected these indicators of the problem:

  • In SonarQube, the warning "Failed to create Bitbucket Server Quality Report for commit SHA ${problematic commit hash}" appears.
  • In the Bitbucket logs, the PUT request to /rest/insights/1.0/projects/${project}/repos/${repository}/commits/${problematic commit hash}/reports/com.sonarsource.sonarqube fails with HTTP 404.
  • The Jenkins build log indicates that merging the main branch into the PR branch at the beginning results in ${problematic commit hash} which is different from the PR head commit, i.e. a merge commit has been created. In builds with successful PR annotation, the resulting commit hash is the PR head commit.

This problem has been discussed in several threads here, one of the central ones is Decorate PR analysis to Bitbucket Server failed. The issue is supposed to have been fixed in SonarQube 7.8, but we use a newer version. I also tried to pass the problematic commit hash via sonar.pullrequest.bitbucketserver.headSha=${env.GIT_COMMIT}, without success.

Another suggestion was to tell Jenkins not to merge the main branch into the PR branch before building. The team has rejected this because it would increase the risk of breaking the main branch build. We would have to do manual work by watching if the main branch has changed during the PR lifetime and merging it into the PR branch. This can be easily forgotten.

These are other options that I see:

  • Use the sonar.scm.revision property instead of the headSha one above. As this is an unconfirmed recommendation by a regular user, can someone from SonarSource comment on it? Which is the right property?
  • Determine the PR head commit hash and always pass that via one of the two properties. Would that work reliably also in the case where code from the local merge commit (which could be vastly different) is analysed?
  • Wait for a solution on SonarSource’s side. Do I read the state of this issue and this PR correctly that this isn’t probable?

Are there more options?

2

I have set the headSha property to the commit hash of the PR branch head instead of the local merge commit and I still see the warning “Failed to create Bitbucket Server Quality Report for commit SHA ${local merge commit hash}”.

I did the same with sonar.scm.revision and that works.

So my first question is answered. As I only see the revision property in the documentation, the properties seem to have changed at some point and the comment from 2019 was simply too old.

sonar.scm.revision=${env.GIT_COMMIT} didn’t work, so I’d still be particularly interested in whether using the PR head commit hash will work reliably in every case:

3

Hi,

You diagnosed and identified the problem correctly: the merge commit. We simply can’t decorate a commit that doesn’t exist on the server.

I don’t have an answer for you. This is not a use case we’ve tried to cover. Our recommendation is not to make the merge commit. If your team finds that unacceptable, then there’s not a lot we can do to help.

 
:woman_shrugging:
Ann

1 Like
4

Thanks a lot, Ann, for the clarification!

Just one last thing that I’m not sure about:

Was that a “Yes, SonarSource likely won’t pursue a solution on their side” to my last question?

5

Hi,

Yes.

 
Ann

6

Thanks again for your quick answers! :slight_smile:

7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.