Possible impact of Jenkins checkout behaviour on SonarQube issue detection

[Delcho (Dichev, Delcho)]

Hello SonarQube Community,

We are using SonarQube Data Center 9.9 along with Jenkins to automate our CI/CD pipelines. For confidentiality, we’ll refer to our pipelines as Pipeline A and Pipeline B. While both pipelines fetch the code from the same Git repository, they use different checkout configurations. Recently, we’ve encountered issues with Pipeline B that don’t occur with Pipeline A, and we’re trying to understand whether the way we check out the code might be influencing these issues.

Background:

1. Pipeline A (Simple Checkout with checkout scm):

• In Pipeline A, we use the default checkout scm step, which is based on Jenkins’ GitSCM plugin. This step checks out the code from the configured branch (e.g., develop) and does not create a local branch but checks out the remote tracking branch (e.g., origin/develop).

• In the Jenkins build summary, the checkout information appears as origin/develop.

• Jenkins checkout info:
  

  

• Checkout step:

checkout scm

• Pipeline A has not shown any issues related to SonarQube analysis. The analysis seems to work fine, with no new issues being flagged on old code (e.g., code from 2013).

2. Pipeline B (Complex Checkout with GitSCM Configuration):

• In Pipeline B, we use a more customized checkout configuration, specifying GitSCM with additional options like branch (*/develop), credentials, and other extensions. This checkout configuration leads to the code being fetched from the remote branch (origin/develop), but the branch information in the Jenkins build summary appears as refs/remotes/origin/develop.

• Pipeline B has shown intermittent issues, where new SonarQube issues are flagged on old code (e.g., from 2013), even though there have been no changes to this code or to any SonarQube rules. These issues seem to appear after running Pipeline B and disappear when we run Pipeline A.

• Jenkins checkout info:
  

  

• Checkout step:

checkout scm: [
    $class: 'GitSCM',
    branches: [[name: '*/develop']],
    doGenerateSubmoduleConfigurations: false,
    extensions: [[$class: 'CloneOption', noTags: false, reference: '', timeout: 60]],
    submoduleCfg: [],
    userRemoteConfigs: [[
        credentialsId: "${credId}",
        url: 'confidential_git_link.git'
    ]]
]

The Problem:

• When Pipeline B runs and completes the SonarQube analysis, new issues are sometimes flagged on old, untouched code (e.g., from 2013). Importantly, no changes were made to these files or to the SonarQube rules.
• After Pipeline B runs, these new issues appear, but when we rerun Pipeline A, the issues disappear, even though there have been no code changes or rule modifications.

We are trying to determine if the differences in how the code is checked out in Pipeline A and Pipeline B could be influencing this behavior, particularly in relation to SonarQube’s analysis process.

Questions:

1. Could the difference in how we checkout the code in Pipeline A (checkout scm vs. explicit GitSCM checkout in Pipeline B) influence SonarQube’s analysis, particularly with regard to flagging new issues on old, untouched code?

2. Does SonarQube depend on the branch structure or specific reference types (like remote tracking vs. local) for analysis, and could this influence how it handles old code that hasn’t been touched?

Our Setup:

• SonarQube Version: Data Center 9.9.7 LTS
• CI/CD Tool: Jenkins
  • Pipeline A: Uses checkout scm (checks out origin/develop as a remote tracking branch).
  • Pipeline B: Uses a more customized checkout configuration (checks out refs/remotes/origin/develop).
  • Both pipelines checkout the latest version of the branch but in different git “structures”

[Colin]

Hey @Delcho

This is a complex issue that will involve sharing a lot of logs, screenshots, specific examples, etc.

If you’re using SonarQube’s Data Center Edition, your organization will have access to Sonar Commercial Support. I suggest you take advantage of this. Unlike this community, raising this issue through commercial support gives you contractual SLAs, confidentiality, etc.

[Delcho (Dichev, Delcho)]

Hello @Colin ,

Thank you for the fast reply! I appreciate your time.

Just to clarify, our SonarQube server is maintained by a different department within the company, which is not very familiar with how we execute the scans, how the files are checked out on the Jenkins slave, and so on. From my previous experience in opening tickets with them and acting as a mediator between us and SonarQube support, I’ve found that it often takes a long time to get a response, and in many cases, the issues remain unresolved.

I’m hoping that, even if full support or guidance might not be possible here, I can receive high-level guidance from the community. For example, insights into how SonarQube uses SCM data and whether there’s a potential difference in how SonarQube reads Git data depending on the checkout methods used in Jenkins. I’ve gone through the documentation, but there are still some details that remain unclear.

If the issue can’t be easily answered or if a high-level response isn’t an option, I can, of course, escalate the issue and open a support request through our support organization.

Thank you once again for your reply. I would really appreciate any high-level guidance or pointers you can offer.

[Colin]

Without seeing the specifics, I can only offer broad generalizations.

Can the SCM checkout affect things like the detection of New Code? Definitely. The detection of New Code is affected by things like whether or not a partial/shallow clone was performed (shallow clones should be disabled), or if the reference branch is available at scan-time (and the Reference Branch New Code Period is being used).

I really encourage you to file a ticket with our Support Team so they can look more closely at the issue.