SonarQube PR decoration inconsistent

SonarQube Server / Community Build
, ,
1
  • which versions are you using
    • SonarQube: Developer Edition Version 8.0 (build 29455)
    • sonar.version: 3.7.0.1746
    • jacoco-maven-plugin.version: 0.8.5
    • maven.surefire.version: 3.0.0-M5
  • what are you trying to achieve: PR decoration on GitHub Enterprise
  • what have you tried so far to achieve this
    • Set the following in the properties of the sonar profile in pom.xml:
      • sonar.host.url
      • sonar.pullrequest.github.repository
      • java.version: 1.8
    • Pass the following arguments in the Jenkins file when executing Sonar:
      • -Dsonar.login=${sonar_token} // This value is defined in the Jenkins server and is static
      • -Dsonar.scm.revisions=${GIT_COMMIT}
      • -Dsonar.pullrequest.key=${env.CHANGE_ID}
      • -Dsonar.pullrequest.branch=${env.CHANGE_BRANCH}
      • -Dsonar.pullrequest.base=${env.BASE_BRANCH}

The above settings along with the correct Jenkins setup lead to Sonar running every time a new PR is opened in the project. A little over half the time the “Checks” tab in the PR on GitHub Enterprise shows the Sonar check as pending even days and days later. The rest of the time the decoration shows as expected.

I’m at rather a loss as to what is causing the issue given that sometimes we get exactly what we expect but others we don’t. I have looked through the past 13 PRs including the one where we added automatic builds of PRs with a SonarQube check. I can find no pattern as to when it will or won’t work other than it almost being every other time that the decoration doesn’t show.

2

Hi,

Welcome to the community!

This is a value you must provide server-side, not analysis side. As you might guess, it is used during PR decoration, and that takes place after analysis parameters are already out of scope. This seems like a smoking gun. Can you correct this & try again?

 
Ann

3

Thanks Ann,
It looks like I’ll have to have someone else configure that part for me then. I don’t see any options for setting the repo name within our SonarQube instance (I’m not an admin).

The value for the repository property is just the username and project name for the repo, not the full URL, not sure if that makes a difference. A race condition would explain why it works sometimes and not others though… I’ll have to track down the person in charge of our Sonar instance and get more info from them I think. Means our docs will need updating too…

4

Found the issue, it was only occurring when the incoming branch was not up to date with the destination branch. If they are in sync then the check appears. This is apparently a GitHub thing.

1 Like