Azure Devops project name missing warning after upgrade to DE 8.6

After upgrading to sonarqube DE 8.6 we’re getting the following warnings on all PR’s:


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 warning is a bug as project name or repository is not required at all for PR decoration to function.

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 logs, you should have a warning message as well with a related message.

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’re adding more work for us with this change, so I would like to know the benefit.

We make extensive use of permission templates and have no need for the ‘import project’ functionality that’s been added. In fact we would like to be able to disable the import project funtionality, as it random generates a project key and thus does not work with the permission templates we use to assign groups to projects…

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 users.

This new onboarding experience is currently discussed between the SQ dev team and PMs, so I’ll make sure to list this thread and your opinion as insight for the discussion. Thanks for sharing your thoughts, it’s valuable to us.

Now, to help you with the situation you face, one possibility you could use is to do API calls to SQ to set these values for each project, with this endoint. The almSetting key is the one you can retrieve here. You could include this call in your build.

About the new vs old behaviour and the deprecation, no hurries. Our deprecation policy is rather conservative, and the detection of parameters from the scanner will keep working for a while.

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 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.

We would love if the more advanced scenario keeps being supported and is extended to gitlab and other ALM’s as well, without it we will have to develop a new way to manage our platform for our sonarqube users and IMO the user experience will not be as good as it is now.

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.2, where we now require the Gitlab project Id. The same warning is displayed if you configured a Gitlab project in 8.1 and did not add the project Id in SQ settings after SQ 8.2.

Thanks for your input!

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

We just tried it on gitlab and it was not working:

There was no merge request decoration.

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.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.