No files showing up in the sonar scan result after turning off shallow fetch

[Stine]

• ALM used: Azure DevOps
• CI system used: Azure DevOps
• Scanner command used when applicable:

dotnet sonarscanner begin \
      /k:"****" \
      /o:"****" \
      /d:sonar.token="${DOCKER_SONAR_TOKEN}" \
      /d:sonar.cs.opencover.reportsPaths="coverage.opencover.xml" \
      /d:sonar.pullrequest.key="${PULLREQUEST_ID}" \
      /d:sonar.pullrequest.branch="${SOURCE_BRANCH_NAME}" \
      /d:sonar.pullrequest.base="${TARGET_BRANCH_NAME}" \
      /d:sonar.pullrequest.provider=vsts \ /d:sonar.pullrequest.vsts.instanceUrl="https://dev.azure.com/****" \
      /d:sonar.pullrequest.vsts.project="****" \
      /d:sonar.pullrequest.vsts.repository="****" \
      /d:sonar.log.level=DEBUG \
      /d:sonar.verbose=true \ 

• Languages of the repository: C#, ASP.NET
• Only if the SonarCloud project is public, the URL
• Error observed:
  After getting help with a previous error on here, my PR’s not getting decorated (which is now fixed) we set out to try and remove the “Shallow checkout” warning. I changed the pipeline to include checkout: self and fetchDepth: 0. Scan still runs successfully, but my PR scan no longer shows any code files scanned or issues in the Sonar Cloud interface.
  
  
  
  
  
  
  I have added issues to the code, which normally would be called out, so I know there are enough changes to produce an error. How can I troubleshoot this? I’ve tried adding the sonar.projectBaseDir as well and tried different paths with no luck, either the scan fails because it can’t find the path provided, or it is like in the pictures, seemingly empty.

We run sonar scan from the dockerfile. If I don’t add the fetchDepth: 0 it works, but then I get the “Shallow checkout” warning.

Here is an extract from our pipeline:

steps:
        # Checkout the repository
      - checkout: self  
        fetchDepth: 0

- task: Docker@2
        displayName: Docker Build
        inputs:
          command: build
          repository: ${{ parameters.containerImageName }}
          Dockerfile: '${{ parameters.buildContext }}/Dockerfile'
          arguments: '--build-arg FEED_ACCESSTOKEN=$(VSS_NUGET_ACCESSTOKEN) --build-arg DOCKER_SONAR_TOKEN=$(DOCKER-SONAR-TOKEN) --build-arg GIT_BRANCH=$(Build.SourceBranchName) --build-arg PULLREQUEST_ID=$(System.PullRequest.PullRequestId) --build-arg SOURCE_BRANCH_NAME=$(System.PullRequest.SourceBranch) --build-arg TARGET_BRANCH_NAME=$(System.PullRequest.TargetBranch)'
          tags: '$(Build.BuildNumber)'
          buildContext: '${{ parameters.buildContext }}'

[Stine]

I’ve now tested this in another project, and I’m getting the 0 files result after adding in the .git folder to the docker container running the scan. Before copying in the .git folder we get the SCM provider autodetection failed warning.

After the .git folder is added I no longer get the warning, but I get an empty scan result showing no files under the “Code” tab.

[Colin]

Hey again @Stine!

Bringing in the .git folder is definitely the right move. If all you’re changing is your Azure Pipelines YML file, I’m not surprised to hear that SonarQube Cloud isn’t identifying any changes.

If you go ahead and make a minor change to an actual code file, do you see the change?

[Stine]

@Stine

I have added issues to the code, which normally would be called out, so I know there are enough changes to produce an error. How can I troubleshoot this? I’ve tried adding the sonar.projectBaseDir as well and tried different paths with no luck, either the scan fails

I did add issues to the code, but they do not show up. I also did notice this:

and this:

Does this have anything to do with it? And how to fix it?
Why does it say 4 changes in the branch in the first portion, then 0 changes a bit later in the run? Still on the same step: dotnet sonarscanner end

[Stine]

What effect does it have if we ignore the “Shallow fetch” warning? Do we lose anything by just using it as it is, as it seems to work when I don’t disable it in the pipeline @Colin ? What are the advantages of turning it off other than making the warning disappear?

[Stine]

I tried just removing the “fetch depth: 0” and scans are working again, but we get these warnings:

The code tab now shows the changed files, and PR comments are again working…

This is why I am asking if we lose any functionality by just keeping it this way. Is this a Docker-specific issue?

[Stine]

@Colin to add to this issue I’ve now run the pipeline twice, once with shallow fetch off, and once with it on and I’ve compared the two pipeline runs in detail. The first thing I’m noticing is that in the working run it looks like this:

And in the failing run (with fetchDepth: 0) it looks like this:

So the working run has an extra folder added to the git directory… Does this help at all?

[Stine]

It looks like I may have figured out the issue on my own finally. With the different folder structures I did some testing and I noticed that when I copied the .git folder, I was copying the .git folder into .git, instead of into the working directory. I don’t know why it was working like that with shallow fetch and not without it, but after changing from COPY .git .git to COPY .git . I now have successful scans with fetchDepth: 0 in my pipeline.