PR decorations applied to pipelines that are not configured to have any

[techlot (A)]

Must-share information (formatted with Markdown):

• SonarQube Enterprise Edition Version 9.9 (build 65466)

Hello,

Recently we have enabled the option for Azure DevOps Platform integration in our SonarQube. We set up a connection to our Azure DevOps Organization PAT.

We have a build pipeline per repo.

Some of our pipelines for different repos in that project already had a SonarQube integrated, but not through the DevOps Platform integration in SQ (so no PR decorations and Quality Gate Check whatsoever)

I observed a strange behavior that some pipelines with existing SonarQube steps started picking up a PR decoration and Quality Gate Check, even though they are not configured to do so (nothing is selected in project settings → devops platform integration for that specific repo, and nothing is selected in policies for the repo in Azure DevOps (Build Status Checks)).

I tried to look into logs and see if the configuration somehow globally affected all the pipelines with the SonarQube steps… But I could not find any hints. Is there some kind of global setting that produces such behavior?

Everything seem to be fine, as we wanted a PR decoration and Quality Gate Check, but it was strange to see it applied to pipelines that we did not set up in that way.

[Colin]

This is a funny quirk of the Azure DevOps integration that was fixed (to the annoyance of some users) in SonarQube v10.0. The short-story is: when PR decoration was first integrated into SonarQube, the necessary information (Azure DevOps URL, repo name) were automatically collected. At some point, we decided it should be explcitly configured in the SonarQube project. We kept the Azure DevOps behavior for backwards compatibility.

So it’s a good idea to make sure each project is well configured anyways, as in SonarQube v10.0 that’s a requirement for PR decoration to work.

[techlot (A)]

Thanks @Colin for the explanation. I figured it’s for the best to configure the checks anyways. Thanks for reassuring that Sonar team is aware of it and works on it.