Quality Gate Status Never Received, Azure DevOps

  • ALM used (Azure DevOps)
  • CI system used (Azure DevOps)
  • Languages of the repository (C#)

We have a pipeline triggered via the creation of a pull request that then invokes a second pipeline in a separate ADO project (passing through a number of variables from the triggering pipeline)

Our project is bound within Sonar (configured as a Mono repo), and we have a valid project-level PAT token (with read and write permissions).

PR Decoration appears to be working and the pipeline job is updated with the output of the scan

However, the quality gate status is never sent back to the PR

I’ve also checked the ADO API

https://dev.azure.com/ORG/PROJECT/_apis/git/repositories/REPO/pullRequests/PRID/statuses?api-version=7.1

and there are no status updates from Sonar.

Within the prepare task we are setting the following;

          projectKey
          projectName
          sonar.cs.vscoveragexml.reportsPathsl
          sonar.sources=src
          sonar.tests=tests
          sonar.exclusions
          sonar.coverage.exclusions
          sonar.pullrequest.key
          sonar.pullrequest.branch
          sonar.pullrequest.base

Is there any additional logging I could enable to investigate this?

If it helps, here is the background task id from Sonar; as far as I can tell everything is working, except for the missing quality gate status

Project Analysis

ID: AZJJLn0GcGOSx8pIQrM8

Hi,

Welcome to the community!

Is there any way you can trigger this again? Very often, these seem to be transient errors on the DevOps Platform side.

 
Ann

1 Like

Absolutely… done, here is the new analysis ID.

Analysis ID: AZJTHJOVvxW-ElunCjs8

Looking at the ADO, API, there are no sonar quality gates created against the pr.

I feel like everything is working; it is just that the server is not publishing the quality gate back to ADO and the pr. :frowning:

Is there anyway to check on Sonar if it is attempting the API call back to ADO to set the quality gate status?

Hi,

Thanks for checking. I’ve flagged this for the team.

 
Ann

1 Like

Hi @PaulD

We checked server logs, and there is indeed an issue while trying to set the status back to the PR.

It seems our service is unable to get the project name and repository slug to decorate. You said that the project is correctly bound. Would you mind double-checking?
Also, if you don’t have an analysis history on this project, you could try deleting it in SonarCloud and importing it again.

1 Like

HI, thanks for getting back to me :slight_smile: :smile: Sorry for the delays.

See below, but unfortunately that has not helped and the status is still not being published from the Sonar Server to ADO.

I’ve removed the project, readded and rescanned, within sonar the project shows as bound

image

I also made sure that the main branch has been scanned a few times.

Analysis ID: AZJmcKnso4E76o_EtrSB

thanks for any help you can provide. - PD.

In case it helps at all, we have also replaced the ADO pat token and rebound, just in case that was causing an issue. Please let me know if there is anything further I can investigate to help solve the issue.

Hey @PaulD ,

I suspect that the second pipeline does not have full information for the Quality Gate report to happen. The Azure prepare task is setting some variables, as seen here, and when you execute it on the second pipeline, which is not in the PR context, it cannot read that info.

In short, I think you might need to pass those variables to your second pipeline:

sonar.pullrequest.vsts.instanceUrl
sonar.pullrequest.vsts.project
sonar.pullrequest.vsts.repository

In any case, what’s the reason for having a different pipeline executed? Why not have PR decoration on the same pipeline as your repository?

I think what you could try is to execute the prepare task in your first pipeline and then pass all properties and ENV variables to the second pipeline as is and execute other tasks.

Hi Jack, thanks for getting back to me. The first pipeline acts as a trigger to the second; so the prepare, analysis and publish all happen on the second pipeline. I’d have to investigate into if its an open to add the prepare to the trigger pipeline.

I did try passing those arguments prior to raising the ticket, but let me retry. I was hoping that as the project is bound directly to the repo in ADO, passing the vtsts details would not be necessary.

Let me update the params, and retest. Thanks for the advice; watch this space.

1 Like

PS, just a quick follow-up question: Do I have to worry about any spaces being escaped in project name?

I think it should be fine

1 Like