SonarQube Quality Gate alerts about issues unrelated to the pull request

SonarQube
,
1

We’ve added SonarQube’s quality gate to our pipeline, but we cannot make it mandatory, because we encounter an issue with it;
Sometimes pull requests fail over QG due to code-smells or bugs that are unrelated to the changes made in the pull request.
It may occur over unchanged lines in files that were changed, or over files that were not changed at all.
In some cases, those issues were pushed to Master a short period of time before the scan, and in other cases, those files have not been touched for years.
Those issues may appear in one pipeline, and disappear the next time a pipeline is ran for the same pull request.
As a result, it is difficult for developers to find which code smells and bugs are related to their changes and which are not.
Also, since no one wants to change code that is unrelated to their PR, the quality gate cannot be a mandatory part of the pipeline.

We are running SonarQube 9.9 (build 65466).
SonarQube is deployed using docker-compose.
Most of the code is written in Java.

2

We’ve had the same issue. In our pipeline yaml we’ve added ‘lockBehaviour: sequential’ for the build stage so that only one build and analysis can run at a time.

It seems a poor solution though.

3

Hi @ahalevi,

Welcome to the community!

This sounds like a problem with the SCM blame data. Can you make sure that the prerequisites are in place?

 
Ann

4

Here’s how our job looks like.
Should we add: git fetch origin “$CI_MERGE_REQUEST_TARGET_BRANCH_NAME” ?

.analysis-job:
  stage: test
  image: maven:3-openjdk-11
  cache:
    - key: $CI_PROJECT_NAME
      policy: pull
      paths:
        - .m2/repository
    - key: ${CI_PROJECT_NAME}_sonar
      policy: pull-push
      paths:
        - .sonar/cache
  variables:
    SONAR_INCLUSIONS: "**/*.java,**/*.kt,**/*.groovy"
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"
    AWAIT_QUALITY_GATE_TIMEOUT: "900"
    GIT_DEPTH: "0"
  script:
    - mvn -f pom.xml -s settings.xml sonar:sonar
      -Dsonar.host.url=${SONAR_HOST_URL}
      -Dsonar.login=${SONAR_AUTH_TOKEN}
      -Dsonar.projectVersion=${BUILD_DISPLAY_NAME}
      -Dsonar.inclusions="${SONAR_INCLUSIONS}"
      -Dsonar.qualitygate.wait=${AWAIT_QUALITY_GATE}
      -Dsonar.qualitygate.timeout=${AWAIT_QUALITY_GATE_TIMEOUT}
      -Dsonar.pullrequest.branch=${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}
      -Dsonar.pullrequest.base=${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}
      -Dsonar.pullrequest.key=${CI_MERGE_REQUEST_IID}
5

Hi,

I’m not a Git-master, but that looks reasonable. I would expect it to be in the part of the job where you do the checkout, though.

And speaking of which,

This seems to come a bit late. I would expect this to also be in the part of the pipeline that handles checkout.

 
Ann

1 Like