SonarQube fails to detect New Issues after the first scan in GitLab CI/CD

Hi @all

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube Server 10.3)
  • how is SonarQube deployed: on-prem

Description: We are currently moving from jenkins to gitlab and want to continue using sonarqube, but we are currently running into an error that we cannot explain. I am facing an issue where SonarQube does not detect new code issues in a feature branch after the first scan. With the first scan everything runs as expected, but after the second scan NEW Code Issues= 0.

Followed the instructions on:

Here is my setup:

  • CI/CD Environment: GitLab CI/CD on gitlab.com
  • Build Tool: Maven
  • SonarQube Parameters:
    • sonar.branch.name=feature/xcxcx, optional, also checked without
    • sonar.newCode.referenceBranch=main
  • Git Configuration:
    • GIT_DEPTH: 0 is set to ensure a full clone.

Problem:

  1. First SonarQube scan correctly detects new issues (NEW CODE ISSUES=1) in the feature branch.
  2. Subsequent scans do not detect new issues anymore (NEW CODE ISSUES=0) and OVERALL CODE ISSUES +1
  3. The New Code period is configured to compare against main , but after the first scan, new issues are missing.
  4. If I now add another issue to the feature branch, it is recognized again after the build (NEW CODE ISSUES=2), but with further builds it is no longer recognized and the Issue is classified as overall code. OVERALL CODE ISSUES +2

Screenshots:

.gitlab-ci.yml

variables:
  MAVEN_CLI_OPTS: "--batch-mode"
  MAVEN_OPTS: "-Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dmaven.artifact.threads=20 -Dmaven.test.failure.ignore=true -Daether.dependencyCollector.impl=bf"

stages:
  - test
  - sonarqube-check
  - vulnerability-report

default:
  interruptible: true
  image: maven:3-eclipse-temurin-17-alpine@sha256:6f85aec7472bf33cdcfa37f79b40ffe6b4a515d8f508d395c43638d6e72c1692
  tags:
    - OnPrem
  cache:
    - key: maven-deps-$CI_COMMIT_REF_NAME-$CI_JOB_NAME_SLUG
      paths:
        - ".m2/repository/"
        - "target/"

junit:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test
    - ls -al

  artifacts:
    reports:
      junit: "target/surefire-reports/TEST-*.xml"

sonarqube-check:
  stage: sonarqube-check
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - mvn $MAVEN_CLI_OPTS -X sonar:sonar
        -Dsonar.branch.name="$CI_COMMIT_REF_NAME"
        -Dsonar.newCode.referenceBranch=main
        -Dsonar.projectVersion=1.0.$CI_PIPELINE_ID
        -Dsonar.host.url=$SONAR_TEST_URL 
        -Dsonar.token=$SONAR_TEST_TOKEN 
        -Dsonar.qualitygate.wait=true
  allow_failure: true

Screenshot from Sonarqube

pom.xml

What I Have Tried:

  • Ensured GIT_DEPTH: 0 is set to avoid shallow clones.
  • Explicitly set sonar.newCode.referenceBranch=main in every scan.
  • sonar.projectVersion changes dynamically (sonar.projectVersion=1.0.$CI_PIPELINE_ID ).
  • Checked logs using mvn sonar:sonar -X to see if SonarQube is comparing against main .
  • Attempted git fetch --unshallow in the pipeline.
  • Confirmed that issues are not marked as “Closed” in the SonarQube UI.
  • Tried deleting and recreating the project in SonarQube.

Questions:

  • Could there be another reason why SonarQube does not detect new code issues after the first scan?
  • Does SonarQube internally set a different reference branch after the initial scan?
  • Are there additional parameters that need to be set to maintain consistency across multiple scans?

Any insights or suggestions would be greatly appreciated!

Thanks!

Hi,

SonarQube 10.3 is pretty old and this point, and definitely EOL. The current version is 2025.1 LTA.

And you’re probably hitting this, which is fixed in the LTA:

SONAR-22265 Successive analyses get the scm info from the reference branch instead of the previous analysis of the branch

 
HTH,
Ann

Hi Ann,

thanks for your reply, but after further testing I’m wondering why it works as expected on the older Sonarqube Server 10.1.

Thanks for the reference, the ticket is about exactly the opposite case.

thx,
Mark

Hi Mark,

Can you do the upgrade and we’ll see if it works as expected again on 2025.1 LTA, a supported version?

 
Thx,
Ann