Typescript detection difference locally and SonarCloud

SonarQube Cloud
1

We’ve recently set up SonarCloud scanning for our NX monorepo and are noticing a difference between the scan results in our Bitbucket pipeline compared to running the scanner locally and uploading the results.

Log from Bitbucket (using sonarsource/sonarcloud-scan:3.1.0)
pipelineLog-{3a0c88bd-bc7d-4d62-98f8-3e79f5ef335e}.txt (43.4 KB)

Log from local run (using npx sonarqube-scanner@latest)
local.txt (36.4 KB)

Our configuration
sonar-project.properties (1.1 KB)

This difference is mainly noticeable in the detection of types in our Typescript codebase. The locally run sonarqube-scanner correctly has type information available and marks errors based on that type information, while the scanner in the Bitbucket pipeline incorrectly marks certain code as an error because it does not have the type information. The biggest marker of the issue is rule typescript:S3735, where it does not know that the ‘void-ed’ function returns a Promise.

Screenshot after local run:

image
image1491×962 147 KB

The local run shows 108 fixed issues and a clear sudden drop in the amount of issues in the graph, indicating that the result is different. (ignore the coverage difference, not all tests had been executed for the coverage upload)

All the configuration is stored in our sonar-project.properties file, besides the SonarCloud token. So the scanners have identical input.

How can there be a difference between the scanning result of sonarqube-scanner and sonarsource/sonarcloud-scan ? And how can we resolve this?

2

Hey there.

Can you provide your Bitbucket Pipelines YML file? The whole thing. :slight_smile:

3

Of course!

bitbucket-pipelines.yml (4.9 KB)

5

Hi Jeroen,

do you run install dependencies on bitbucket (ie npm install or equivalent)? If not, the types will not be available for the analysis.

Best,

Tibor

6

That’s a good point. I don’t think the step currently has access to the node_modules. I’ll attempt it and report back!

7

Running npm install seems to have done the trick, thanks for the suggestion!

1 Like
8

Hey @PB_Jeroen_A

This might be a dumb question, but do you know what npm install is doing differently than what you were already doing in your pipeline?

- step: &Install
    caches:
      - cypress
      - node
    name: Install dependencies
    image: *node
    script:
      # Skip install if node_modules is already present and not empty.
      - files=$(shopt -s nullglob dotglob; echo node_modules/*); if (( ${#files} )); then exit 0; fi
      - export ARTIFACTORY_TOKEN=`curl --silent --show-error --fail -u $ARTIFACTORY_USER:$ARTIFACTORY_PASSWORD https://artifactory.portbase.io/artifactory/api/npm/auth | grep -oP '_auth = \K.+'`
      - echo "//artifactory.portbase.io/artifactory/api/npm/fontawesome:_auth=${ARTIFACTORY_TOKEN}" >> .npmrc
      - npm ci --foreground-scripts

I didn’t suggest npm install because I assumed it was already happening here!

9

The node_modules folder from the install step is saved in our node cache, but we never gave Sonar access to that cache. So it didn’t have the dependencies “installed”.

  caches:
    node:
      key:
        files:
          - package-lock.json
      path: node_modules

   <snip>

    - step: &Sonar
        size: 8x
        name: SonarCloud analysis
        script:
          - pipe: sonarsource/sonarcloud-scan:3.1.0
            variables:
              SONAR_SCANNER_OPTS: -Xmx4096m

The fix:

    - step: &Sonar
        size: 8x
        caches:
          - node
        name: SonarCloud analysis
        script:
          - pipe: sonarsource/sonarcloud-scan:3.1.0
            variables:
              SONAR_SCANNER_OPTS: -Xmx4096m
2 Likes
10

Thanks for following-up!

12

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