After upgrading to sonarqube DE 8.6 we’re getting the following warnings on all PR’s: [image] However PR decoration and quality gate reporting on azure devops is working perfectly fine. possibly related to my other topic here: Clarification on pull request decoration docs But clearly this warnin…

Hi, the previous behaviour was to use the Azure repo+project name found in the scanner context. For compatibility, this will still work for a couple of SonarQube versions. The new behaviour is to use SonarQube projects settings, on project ALM Configuration. If you look at your scanner analysis lo…

What reason do you have to change this functionality? We are super happy that it works this way currently, no need to setup ANYTHING in sonarqube. Just works out of the box. New project in source control? Just start a build and a sonarqube project is created, analyzed and result pushed to PR. You’r…

You guessed right, the reason of this change is to go along with the new “import project” feature, that we call onboarding, that includes the creation of the SQ project + a tutorial to guide new users through the SonarQube configuration of a first project. And it’s not designed for more advanced use…

Good to hear that there is no rush on the deprecation! Since it’s only a warning we do not mind, just alerted me to some changed behavior which made me worried for the future. But thanks for the suggestion about using the API. I assume then that it also explains my questions in the other thread ab…

[image] Rouke.Broersma.IS: I assume then that it also explains my questions in the other thread about gitlab. Since gitlab decoration was created later I assume the auto-detection of the correct properties was never built, with the new behavior in mind. Actually, the exact same patterns apply…

We were looking for that property! We’ll try that out, thanks!

[image] pierreguillot: Actually, the exact same patterns apply to Gitlab as well. The first solution we implemented with SonarQube 8.1 relied only on gitlab-runner env variable CI_PROJECT_ID , which is still working right now. And we then moved to SQ project-level configuration with SonarQube 8.…

yes, it only works if you configured your project in SQ 8.1 (when the project key was not needed), and then upgraded to SQ 8.2+. If you start using Gitlab after SQ 8.1, there is no way to bypass the mandatory SQ project configuration. Sorry for the confusion.

Is that also for azure devops? :o

Yes, starting with SQ 8.6 you can’t configure a new project with Azure without adding configuration to SQ UI (or API).

Okay that is unexpected. We have multiple customers using the old way with azure devops. This should IMO have been in the changelog as it literally breaks a feature for us. Thank you for your help with this, we’re going to have to contact our customers asap now that we know.

Azure Devops project name missing warning after upgrade to DE 8.6

SonarQube Server / Community Build

Rouke.Broersma.IS (Rouke Broersma) January 19, 2021, 8:21am 15

@pierreguillot I’m getting conflicting information now from @Colin here: Pull Requests Analysis and Feedback

So I would love to know who is correct here

Topic		Replies	Views
Pull Requests Analysis and Feedback SonarQube Server / Community Build sonarqube	13	1538	June 21, 2021
Clarification on pull request decoration docs SonarQube Server / Community Build	2	1118	January 7, 2021
Full list of possible pull request decoration parameters SonarQube Server / Community Build	7	1751	July 27, 2021
Pull Request decoration i Azure Devops not working SonarQube Cloud azuredevops , sonarqube-cloud	13	3371	March 10, 2022
PR decoration is empty in Project Settings for a new project SonarQube Server / Community Build sonarqube , bitbucket , pull-request	12	3317	August 19, 2020

Azure Devops project name missing warning after upgrade to DE 8.6

Related topics