# Azure DevOps integration settings lost for all SonarQube projects **URL:** \ **Category:** SonarQube Server / Community Build\ **Tags:** azuredevops, sonarqube\ **Created:** [May 23, 2023, 8:16am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289 "2023-05-23T08:16:31Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![HBalint94](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/hbalint94/32/45335_2.png) [@HBalint94](https://community.sonarsource.com/u/HBalint94)\ **Post date:** [May 23, 2023, 8:16am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/1 "2023-05-23T08:16:31Z")
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! ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [May 24, 2023, 8:19am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/2 "2023-05-24T08:19:06Z")
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](https://community.sonarsource.com/t/sonarqube-10-0-not-reporting-quality-gate-status-and-pr-decoration-in-azure-devops/89183/10): > > 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](https://marketplace.visualstudio.com/items?itemName=SonarSource.sonarqube)) 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](https://github.com/SonarSource/sonar-scanner-vsts/commit/dfb15205a2546018064e6ebd1f1ddd75624301cb). Are you sure all your build agents are using the updated extension (nothing being cached)? ---
**Author:** ![Tom\_Pester](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tom_pester/32/16549_2.png) [@Tom\_Pester](https://community.sonarsource.com/u/Tom_Pester)\ **Post date:** [October 30, 2024, 2:41pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/3 "2024-10-30T14:41:03Z")
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](https://community.sonarsource.com/t/sonarqube-10-0-not-reporting-quality-gate-status-and-pr-decoration-in-azure-devops/89183/17) I normally don’t repost to be clear. ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [October 30, 2024, 3:48pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/4 "2024-10-30T15:48:08Z")
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. ---
**Author:** ![Tom\_Pester](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tom_pester/32/16549_2.png) [@Tom\_Pester](https://community.sonarsource.com/u/Tom_Pester)\ **Post date:** [October 31, 2024, 9:25am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/5 "2024-10-31T09:25:59Z")
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 ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [November 1, 2024, 6:29pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/6 "2024-11-01T18:29:09Z")
Split this topic on November 1, 2024, 6:29pm UTC 2 posts were split to a new topic: [SonarQube PR analysis raising thousands of issues on existing projects](https://community.sonarsource.com/t/sonarqube-pr-analysis-raising-thousands-of-issues-on-existing-projects/129673) ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [November 1, 2024, 6:28pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/8 "2024-11-01T18:28:45Z")
> [@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. > [@SonarQube PR analysis raising thousands of issues on existing projects](https://community.sonarsource.com/t/sonarqube-pr-analysis-raising-thousands-of-issues-on-existing-projects/129673/1): > > 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. ---
**Author:** ![Tom\_Pester](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tom_pester/32/16549_2.png) [@Tom\_Pester](https://community.sonarsource.com/u/Tom_Pester)\ **Post date:** [November 5, 2024, 10:38am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/9 "2024-11-05T10:38:20Z")
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) ![image](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/9/3/93056efb878a355a914461278fb000ca7e75df2b.png) 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 ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [November 5, 2024, 8:18pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/10 "2024-11-05T20:18:08Z")
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](https://community.sonarsource.com/t/sonarqube-pr-analysis-raising-thousands-of-issues-on-existing-projects/129673)) 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](https://docs.sonarsource.com/sonarqube/latest/server-upgrade-and-maintenance/release-notes-and-notices/release-upgrade-notes/#release-10.0-upgrade-notes)]. ---
**Author:** ![Tom\_Pester](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/tom_pester/32/16549_2.png) [@Tom\_Pester](https://community.sonarsource.com/u/Tom_Pester)\ **Post date:** [November 6, 2024, 8:37am UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/11 "2024-11-06T08:37:19Z")
> 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) ---
**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\ **Post date:** [November 6, 2024, 9:26pm UTC](https://community.sonarsource.com/t/azure-devops-integration-settings-lost-for-all-sonarqube-projects/91289/12 "2024-11-06T21:26:16Z")
These properties are getting auto-configured (see [here](https://github.com/SonarSource/sonar-scanner-azdo/blob/85323d60f68992e2c8560833327432288f185467/src/common/sonarqube-v5/prepare-task.ts#L101)), 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.