Azure DevOps New Code Analysis Multi target branches

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 have a project that is not using any branch strategy known, we have a build pipeline with the configuration as shown bellow

image
image1920×711 56 KB

But there are multiple pull requests that are merging into different branches

image
image2096×1031 179 KB

  • what have you tried so far to achieve this

Actually wanted any suggestions on how to advance with this type of scenario or problem presented, anything is valid. Toughs so far:

  • Creating one build pipeline for every branch (Will be hard)
  • Is there any way that the “target branch” could be a variable for the comparison of the new code? Our configuration is like this

image
image1253×542 18.6 KB

2

Hey there.

When performing Pull Request Analysis, sonar.pullrequest.target should be automatically detected in your pipeline.

How is your pipeline configured today? Could you be setting something like sonar.branch.name which is overriding the PR analysis (and auto-detection of these parameters)?

3

Hey Colin, thanks for the response, here is the configuration earlier done by the old team. (The configuration has been set in the pr.yml file

sonar.cs.opencover.reportsPaths=**/coverage.opencover.xml
sonar.verbose=true
sonar.projectBaseDir=.

The folder structure is like this

.
├── .ado
│   └── pr.yml
├── API (Project)
│   └── src
│       ├── API
│       │   ├── api
│       │   └── tests
│       └── Service
│           ├── service
│           └── tests
4

I’m not sure I have the full picture. It would probably be useful if you posted the full pipeline logs from the steps running SonarQube analysis in your build, where you expect a PR analysis.

The complete Azure Pipelines YML would also be good to share.

5

Ok sure more info about the pipeline

Also, after reading you may notice that there is a for loop in tests :hushed: those tests are send via parameter like

tests:
    - name: api.tests
    - name: service.tests

Actual yml the important part

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
      sonar.projectBaseDir=.

- 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
6

Hey there.

Thanks for the details!

I think what’s going on is that while you have the analysis running on each commit to the branches you’ve specified, you aren’t actually triggering on the PR using a branch policy – or at least, if you are using a branch policy, the build in that policy might not include SonarQube analysis.

Could that be what’s going on?

In this case, you would get a branch analysis, and while you could fiddle around with sonar.newCode.referenceBranch to dynamically define the reference branch in your pipeline… I think what you’re really after is pull request analysis.

1 Like