We notice SonarQube not returning the quality gate status check from Pull Requests when we don’t explicitly set the DevOps Platform Integration for each project separately (until now, we never needed to). We have a lot of projects, and we only configured the Azure DevOps settings in: Administration → Configuration → General Settings → DevOps Platform Integrations.
After upgrading to SonarQube 10.0, most projects with builds in Azure DevOps stopped reporting back the SonarQube quality checks and PR Decorations to the pull requests. Only the projects which had the Azure DevOps stored in the Project Settings kept reporting back. So there is a work around, but we don’t prefer storing those settings for almost 500 projects.
I noticed the following message in the SonarQube tasks for Azure DevOps:
##[debug][SQ] API GET: '/api/server/version' with query "undefined"
##[debug]Response: 200 Body: "10.0.0.68432"
##[debug]SonarQube version < 7.2.0 detected, falling back to default location(s) for report-task.txt file.
Task versions:
##[debug]Task 'SonarQubePrepare' already downloaded at '/agent/_work/_tasks/SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157/5.13.0'.
##[debug]Task 'UseDotNet' already downloaded at '/agent/_work/_tasks/UseDotNet_b0ce7256-7898-45d3-9cb5-176b752bfea6/2.219.0'.
##[debug]Task 'DotNetCoreCLI' already downloaded at '/agent/_work/_tasks/DotNetCoreCLI_5541a522-603c-47ad-91fc-a4b1d163081b/2.217.0'.
##[debug]Task 'PublishCodeCoverageResults' already downloaded at '/agent/_work/_tasks/PublishCodeCoverageResults_2a7ebc54-c13e-490e-81a5-d7561ab7cd97/1.219.0'.
##[debug]Task 'SonarQubeAnalyze' already downloaded at '/agent/_work/_tasks/SonarQubeAnalyze_6d01813a-9589-4b15-8491-8164aeb38055/5.13.0'.
##[debug]Task 'SonarQubePublish' already downloaded at '/agent/_work/_tasks/SonarQubePublish_291ed61f-1ee4-45d3-b1b0-bf822d9095ef/5.0.2'.
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 scanner. We would like to make this easier in the future (especially for large instances) and you can vote on this card here.
On my side, I will push for a clear upgrade note in the Upgrade Notes.
We’ve added a more specific note in the Upgrade Notes:
Deprecated pull request configuration properties removed
DevOps Platform Integration settings are no longer inferred from scanner-level analysis parameters, which were deprecated in SonarQube 8.1. To prevent pull request decoration from failing, make sure you have configured each project with the settings found under the project-level Project Settings > DevOps Platform Integration.
This particularly affects users integrating with Azure DevOps who formerly relied on the Extension for Azure DevOps to pass these properties. (SONAR-17711).
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.