PR Decorators on Azure DevOps - file no longer exists in the latest pull request changes

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • SonarQube Server: 9.9.2
  • how is SonarQube deployed: zip
  • what are you trying to achieve

We are trying to enable pull request decorators but there appear a lot of comments and files that no longer exists.

image
image801×102 5.41 KB

image
image970×581 25.3 KB

  • what have you tried so far to achieve this

I’ve already read another related issue (Azure Devops PR Decoration issue: This file no longer exists in the latest pull request changes) and try to implement the “sonar.projectBaseDir=” but with no luck

2

Hey there.

Can you share your full Azure Pipelines YML configuration? Don’t leave anything out, at least until after SonarQubeAnalyze. :slight_smile:

I’d also like to know:

  • Does this happen after the first analysis of a PR or after subsequent analyses?
  • Are the files referenced (the ones that are decorated) files that indeed changed in the PR?
3

Hi Colin,

Was trying so many things right now jejeje well getting back again to you

For the questions

  • Happens after subsequent analyses (And it doesnt always appears) is like is Hallucinating. Also tried to add a schedule.yaml pipeline to run daily main scans
  • The files appear in the folder after checking the branch

image
image1447×472 88.9 KB

Also add a Tree /F command to check how was the folder doing on the project

image
image828×681 33.2 KB

Full pipeline

trigger: 
  branches:
    include: 
    - bug*
    - fix*
    - pbi/*
...

...
- task: SonarQubePrepare@5
  displayName: 'Prepare analysis on SonarQube'
  inputs:
    SonarQube: ${{ parameters.sonarQubeServerEndpoint }}
    projectKey: ${{ parameters.sonarQubeProjectKey }}
    projectName: ${{ parameters.sonarQubeProjectName }}
    extraProperties: |
      # Additional properties that will be passed to the scanner
      sonar.cs.opencover.reportsPaths=**/coverage.opencover.xml
      sonar.verbose=true

- task: DotNetCoreCLI@2
  displayName: 'Restore ${{ project.name }}'
  inputs:
    command: restore
    projects: '**/${{ project.name }}.csproj'
    feedsToUse: select
    vstsFeed: $(bofiNugget)
    includeNuGetOrg: true

- ${{ each test in parameters.tests }}:
  - task: DotNetCoreCLI@2
    displayName: 'Build ${{ project.name }}'
    inputs:
      command: build
      projects: '**/${{ project.name }}.csproj'
      arguments: '--output $(Build.BinariesDirectory) --configuration Release'

  - task: DotNetCoreCLI@2
    displayName: '.Net test ${{ test.name }}'
    continueOnError: ${{ parameters.testsContinueOnError }} # If .Net test fails, reports will not be generated
    inputs:
      # Explanation:
      # This will generate a report on every folder of tests with name 'coverage.opencover.xml'
      # - CoverletOutputFormat: Format output of report 'opencover' for SonarQube tasks
      # - CollectCoverage: To generate the report
      arguments: '/p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:ExcludeByAttribute="DbContext"'
      command: test
      projects: '**/${{ test.name }}.csproj'
      publishTestResults: ${{ parameters.publishTests }}

- task: SonarQubeAnalyze@5
  displayName: 'Run Code Analysis on SonarQube'
  inputs:
    jdkversion: ${{ parameters.sonarQubeJdkVersion }}
  continueOnError: true

- task: SonarQubePublish@5
  displayName: 'Publish Quality Gate Result on SonarQube'
  continueOnError: true

I would really like to show everything but because NDA I can’t, what about something odd like a meeting call :pray: (Pary for mercy)

4

So it only happens on subsequent analyses, and never the first? That’s what I’m trying to get at.

5

It happened on subsequent analysis, but I think the branches are not following the practices of cloning back again “main” branch

I don’t understand how the process of compression is from one “feature/something_1” into “main”. Could you explain that part please?

When we start first analysis on main and create a new branch “feature/something_1” from that point, then get back into running “schedule” analysis in “main”, what will happened to “feature/something_1”?

Maybe need some examples to clarify this

6

Hi Colin, after reading and adding different aproaches like:

sonar.projectBaseDir=$(Build.SourcesDirectory)

still facing issue so well, that is the update