Azure DevOps integration settings lost for all SonarQube projects

[HBalint94]

The issue is that after we updated the sonarqube version we lost all the Azure DevOps integration settings for all (more hundred) SonarQube projects which means that we can’t use the SonarQube/quality gate on our Pull requests anymore in VSTS.

Also in our VSTS builds for Publish Quality Gate Result task we can see the following log:
##[warning]No analyses found in this build! Please check your build configuration.
We are using the 5.13.0 (latest) Azure Devops extension.

• sonarqube version: 10.0.0.68432
• how is SonarQube deployed: zip
• So we want to have those settings filled automatically by SonarQube as it was the case before the update.
• A workaround is that we manually set the Azure DevOps integration settings but that’s not really an option since as mentioned we have more hundreds of projects where we should do this setting.

Any hint would be really appreciated!

Thanks in advance!

[Colin]

With regards to the Azure DevOps integration details, take a look here.

SonarQube 10.0 not reporting quality gate status and PR decoration in Azure DevOps

Hey all. In SonarQube v10.0, we removed some deprecated analysis parameters which, among other things, automatically fed the ALM Integration information when in an Azure Pipelines context (using the Extension for Azure Devops) This was old behavior, kept for compatibility reasons, and we’ve encouraged users to set the ALM integration configuration in their Project Settings for some time now. Right now, there’s no method of automatically populating this data from information available to the s…

With regards to this:

@HBalint94

Also in our VSTS builds for Publish Quality Gate Result task we can see the following log:
##[warning]No analyses found in this build! Please check your build configuration.
We are using the 5.13.0 (latest) Azure Devops extension.

That’s definitely odd, as this should be fixed in v5.13 of the extension. Are you sure all your build agents are using the updated extension (nothing being cached)?

[Tom_Pester]

Does SonarSube really understand the impact of his on their clients using Azure DevOps ?(?).

We are force to reconfigure 70 (!) projects. I read that we are lucky as there are client that need to take actions on 500 projects.

I already planned some time next week for these 70 projects but now I got the feedback that a lot of decisions that were made previously have to be re-takane again.
For us we are talking about noise generated on our pull request that represent 75K (!N) thousands issue.

Why this decisision was taken is unclear to me but I think it was an optimisation on SonarQube side to make their lives easier.
Sorry, excuse me.

This is adressed by an update to the release notes. Are we an edge case? I don’t understand what you are doing SonarQube.

This is a repost from SonarQube 10.0 not reporting quality gate status and PR decoration in Azure DevOps - #17 by Tom_Pester
I normally don’t repost to be clear.

[Colin]

Hey @Tom_Pester

I agree with you. Recently we had some discussions on this toipc and I’m happy to tell you that we will be reenabling the old parameters before the next LTA version of SonarQube (scheduled early Q1) while we find a better solution to handle binding, without a lot of manual configuration.

[Tom_Pester]

Hello @Colin ,

Thanks for the empathy
What does that mean for us today? Should we wait for a new release?

We have SonarQube turned off for now and would like that this situation doesn’t last that long.

We are running a paid Developer Edition. Thank you

SonarQube ID information
Server ID: redacted…U5RyM
Version: 10.6.0.92116
Date: 2024-10-31

[Colin]

@Tom_Pester

Thanks for the empathy
What does that mean for us today? Should we wait for a new release?

Well, you are welcome to configure the 70 projects so that you can continue working as expected. Until we reenable those parameters, there’s no other solution for v10.x versions.

@Tom_Pester

Another more pressing issue at this moment that prevents us from enabling SonarQube again on our most used projects by doing the manual intervention, is that we get all issues (7.5 thousand) posted on our pull request instead of the newly introduced ones,

I think we can consider that these issues are completely unrelated.

I am going to split off this other issue into a new thread.

[Tom_Pester]

To the others who are upgrading
These were the changes necessary to get our integration with the PR timeline going again
(We still have an open issue (129673) with scannermode=cli tasks)

So

1. Configure SonarQube server
2. The sonarqube.pullrequest properties are not neccessary anymore because of 1. and/or that this information is automatically extracted when using git
3. A full checkout is now required whereas in the past a sparse checkout would do (was a bit more performant)

@Colin Does this change look what you expect and is this documented somewhere?

Thank you

[Colin]

Hey @Tom_Pester

• We always recommend a full checkout. I think this links back to the cache issue (SonarQube PR analysis raising thousands of issues on existing projects) which is still to be followed up on by our devs.
• Explicitly setting the sonar.pullrequest properties were never necessary when using the Azure DevOps integration (they were auto-configured behind the scenes). For now, they’ll be ignored, but by the next LTA, they will be working again. You should not need to explicitly set them at that point.

So on my end, right now, nothing that needs to be explicitly documented other than the already referenced [upgrade note](Release upgrade notes].

[Tom_Pester]

Explicitly setting the sonar.pullrequest properties were never necessary when using the Azure DevOps integration (they were auto-configured behind the scenes).
For now, they’ll be ignored, but by the next LTA, they will be working again. You should not need to explicitly set them at that point.

Ok, but something isn’t clear to me. So we now have to set repo and project information on the SonarQube server since V9>V10 (we 70, other 500 manual changes).
But the sonar.pullrequest.* properties were always ignored by the Azure DevOps integration?
Not so right, as in V9 information was send to SQ Server so we didn’t have to manually configure it there (as we do now)

This is just for clarification as I may be somehting missing. This topic can be closed as the problem at hand is solved and we are on @7 for scannermode=datnet
(the other isse scannermode=cli is still open)

[Colin]

These properties are getting auto-configured (see here), and in SonarQUbe v9.9 that are being used to execute the PR decoration. Now they are still getting set, but they are being ignored by SonarQube 10. We will stop ignoring them (revert the behavior) for the next LTA version.

This is all unrelated to the change in task version.