Azure Devops PR Decoration issue: This file no longer exists in the latest pull request changes

  • ALM used: Azure DevOps
  • CI system used: Azure DevOps
  • Scanner command used: Generic scanner on Azure Pipelines
  • Languages of the repository: .NET C#


I’m experiencing a strange issue with the PR decorator in Azure Devops. I have the PAT generated for my user and linked correctly for the project with the correct scope applied ‘Code (read and write)’.

However, any comments made within a file on the PR by the decorator are stating that “This file no longer exists in the latest pull request changes. It may have been moved or deleted.”. It does not matter where or what the file is, and even though the file most definitely exists and has not moved, I get this same result in every single comment:

The only way to view the comment made on the PR inline is to click the “See it in SonarCloud” link and view it within the sonar cloud portal, which is obviously not ideal or expected behavior.

I even generated a new PAT and tried including the scope ‘Pull Request Threads (read and write)’ but get the same result. Also, testing with a different user renders the same result as well.

Along these lines, I’m wondering if/when there will be an option to toggle the pull request decorator on/off for Azure Devops integrations similar to how it was implemented for GitHub after enough people complained about not having the option to do so. I see a ticket was opened here not too long ago but it hasn’t gained any traction Allow users to opt-out of pull request decoration on Azure DevOps.

In my opinion, this feature needs to be addressed. I’m in the process of rolling out sonarcloud across our applications within our organization, and any time I add the sonar steps to the build pipeline for an application and PR those changes to our repos, sonar cloud will automatically spam the first PR containing any changes with 50+ comments pointing out existing issues that weren’t introduced in the PR. I believe this happens because it’s treating this initial scan as the “new code” baseline, which is extremely disruptive and counter intuitive. This problem alone is what has made us hesitant to even implement sonar cloud in the first place as it is very disruptive for any developers working in the repos as the scan steps are implemented.

Anyway, any info on these 2 issues (PR decorator file not found issue and ability to disable PR decorator in Azure Devops) would be greatly appreciated. Thank you!

Hey there.

A user faced a similar issue here:

Can you check that this project is bound to the repository you expect (the repository where your Pull Requests are being raised)? It means that this link on your SonarCloud project (the one you’re taken to when you click See it in SonarCloud) should take you to the right repository.

Hm. That shouldn’t be happening. Does this happen even if the target branch of the PR (like master) has already been analyzed?

Hey Colin,

Thanks for the reply! Below are my responses, thanks again for your help!

Can you check that this project is bound to the repository you expect (the repository where your Pull Requests are being raised)? It means that this link on your SonarCloud project (the one you’re taken to when you click See it in SonarCloud ) should take you to the right repository.

I was able to confirm that my project is bound correctly, the link you pasted in the screenshot takes me directly to the repo I would expect.

Hm. That shouldn’t be happening. Does this happen even if the target branch of the PR (like master ) has already been analyzed?

The only PR that gets spammed with comments about existing issues is the first PR created after the project CICD is setup to run through the analyzer. Any subsequent PR’s after that initial one only receive comments from the decorator if the issues are new which is what I would expect.

@Colin any other thoughts on this? I’d like to get this resolved as it’s holding up our implementation of SonarCloud across our organization.

I noticed something while troubleshooting that I think is the issue but there’s no clear way to solve it.

The file commented on by the PR decorator appears to be nested one level too deep compared to a manual PR comment made in the same file. How could this be? I tried manually setting sonar.sources to be more specific but that makes no difference.

Hi @jdinardo,

I’m very sorry for the late reply.
Do you still have the “This file no longer exists…” issue?

Hi @Claire_Villard

I believe I have an identical issue, where the repository name is being prefixed in the path. I’m afraid I’ve raised a separate thread, as I thought it was unrelated at first, but now I think it is probably the same issue I’m having

@Claire_Villard I was…
My organization has already canceled our plan as we did not want to implement scans into our pipelines with this issue going unresolved.

@TScamell Glad to see I’m not alone, I could not find anyone else with a similar issue. If you find a solution I would love to hear it so please let me know. Thanks!

@jdinardo I’ve got it working for me now :slight_smile:

I had to set
sonar.projectBaseDir (and make sure master branch has built first using this configuration, otherwise it will have nothing to compare against).

I believe it affected us since we changed our yml build pipelines to pull from multiple repositories. When you have this, it appends the repo name in your checkout directory. This then creates the duplicated folder structure you see in SonarCloud and on the annotated PRs that the file is now “missing”.

We now use the SonarCloudPrepareConfiguration:

 - task: SonarCloudPrepare@1
    displayName: "Prepare SonarCloud"
      SonarCloud: '$(tfsSonarCloudServiceConnectionName)'
      organization: '$(sonarCloudOrganisation)'
      scannerMode: 'MSBuild'
      projectKey: '$(projectName)'
      projectName: '$(projectName)'
      projectVersion: '$(Build.BuildNumber)'
      extraProperties: |
    condition: and(succeeded(), eq('${{ parameters.runDefaultSonarSteps }}', true) , or(eq(variables['Build.Reason'], 'PullRequest'), eq(variables['Build.SourceBranch'], 'refs/heads/master'), startsWith(variables['Build.SourceBranch'], 'refs/heads/teams/')))

Where $(projectName) for us is a build variable that matches both the repo name, and sonarcloud project name.

Hope this works for you!


Thanks a lot @TScamell for providing a detailed solution to that issue!

@jdinardo If ever you give the product a second chance, I would be happy to know if the fix works for you too. If it doesn’t, I’ll be happy to help you further.


That’s awesome, thank you so much for sharing!!

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