Where can I go to get a deeper understanding about how pull request integration works?

I coach a number of teams on their engineering practices and I’m wanting to gain a deeper understanding of how pull request integration with SonarQube works.

I’ve already delved into the source code behind the Azure DevOps extensions and have a good understanding of how an Azure DevOps build agent interacts with the SonarQube server when a developer inserts SonarQubePublish@5 into their pipeline. I know how the status report is generated and uploaded to Azure DevOps so it appears in the UI of a pipeline run.

In the process I discovered that if the task times out, it puts a warning into the pipeline logs but then misleadingly sets the Sonarglobalqualitygate to “ok”. So developers expecting to use this build property to detect a quality gate failure may see pipelines unexpectedly complete successfully if the SonarQubePublish@5 times out waiting for the analysis to finish.

I want to understand the mechanism underlying pull request decorations just as intimately but I’m having a difficult time finding what I’m looking for. The documentation primarily focuses on the steps needed to set up and configure things using the UI but there’s little information on the process flow.

I did find a single link to Microsoft’s documentation on the pull request status API. This documentation describes steps for writing your own status service as well as the sequence of events that take place when a pull request is created or updated. I can only assume that the SonarQube server is designed to act as a pull request status service and that if I knew where to look I could examine the source code and see the steps it takes in response to new or updated pull requests. If this part of SonarQube is proprietary I don’t actually need to see the source. I’d just like to understand the event sequence.

Hey there.

SonarQube processes the Pull Request Analysis and then makes API calls to Azure DevOps to update the PR with comments, as well as a status check that can be used to block the merge of the PR if it’s failing.

This is entirely separate from SonarQubePublish – which is just tagging the build (PR or not) with a Quality Gate status.

You can use SonarQubePublish without having the PR decorated, and you can use PR decoration without SonarQubePublish

The underlying code for PR decoration is proprietary.

Are the these calls to AzDo triggered when a SonarQubeAnalyze@5 task is executed?

They’re triggered when the analysis report is being processed (right at the end). The analysis report is what is submitted to SonarQube by the SonarQubeAnalyze task, which the Compute Engine (server-side) processes. This is what we call background tasks.